Failed to decompile `main` in stripped 32-bit x86 binary

[RocketMaDev]

Describe the bug Check the screenshot below. Ghidra could resolve symbols in disassembly, but the decompilation is so redundant. Arguments pushed onto the stack piled up and significantly impact my decompilation experience. The weirdest thing is that only main is incorrect.

To Reproduce Steps to reproduce the behavior:

1. Import the sample
2. Run auto analysis
3. Check the stripped main

Expected behavior Decompilation should look like the same as other funtions.

Attachments Sample: httpd.gz

Environment (please complete the following information):

• OS: Arch Linux
• Java Version: 21.0.4
• Ghidra Version: 11.1.2
• Ghidra Origin: official GitHub distro

Additional context I have mod some function names, but I have no idea about how to upload my database.

[ghidra1]

The fullsize image attachments are unavailable and those that appear above are too small to read.

[ghidra1]

The assembly listing uses a completely different approach to markup and does some degree of speculation on what may appear to be a memory offset which in many cases correspond to existing Data or a symbol. In the case of the decompiler, it relies more data type info for constants and possibly symbols when an pointer type or memory access is involved.

Since I am unable to view your images (click to enlarge produces error) I am not entirely clear on what specific issue you are concerned with.

[ghidra1]

I can now see the images enlarged. I think my comment above still applies.

[RocketMaDev]

I see. Is there a quick solution to make calls inline? Take picture 1 for an instance,

*(int *)(puVar7 + -0x1148) = iVar6 + 0x1bea;
*(undefined4 *)(puVar7 + -0x114c) = 0x1147a;
iVar5 = chdir(*(char **)(puVar7 + -0x1148));

should at least be made inline like:

iVar5 = chdir(iVar6 + 0x1bea);