gcc/objdump output containing lines from C source code among the lines of disassembled ASM code

Question

I believe this question is significantly different from other, similar questions.

My flow is roughly this:

### Compile
%> gcc -ggdb3 file0.c ... -fno-builtin -c -o file0.o
%> gcc -ggdb3 file1.c ... -fno-builtin -c -o file1.o
...
%> gcc -ggdb3 fileN.c ... -fno-builtin -c -o fileN.o
### Link
%> gcc -ggdb3 -nostdlib -nodefaultlibs -Tscript.lds -Ttext=0x4000000 \
          -Wl,--build-id=none -o main.elf file0.o file1.o ... fileN.o
### Disassemble
%> objdump -Stsxd main.elf > main.dis

I do not see the C code between lines of the disassembly file produced by objdump. See the image below for an example.

I don't blame objdump, because objdump --dwarf=decodedline main.elf shows nothing. I don't think the information is in the elf file.

• I've fiddled with adding -g, -ggdb, and -gdwarf of various versions.
• I've put full pathnames to files instead of relative paths.
• I've tried -O0 to -O3.
• The only flags not shown in my flow above are -W, -D, and -I flags.

If it matters, I'm using the Linaro port of gcc 6.4.1 targeting Cortex-A72 clusters. (My build machine is CentOS 7.9 on x86_64.) The commands to gcc and objdump above are prefixed to use that gcc version, and I see its banner from the debug section of the ELF in the disassembly file.

Is there some flag I am missing, or perhaps something I am adding (like -fno-builtin, or -Wl,--build-id=none) that could cause this? Could my linker script file be stripping required information out, even though I provide a "debug" section (for .debug_info, .debug_line, and many other sections)? Both objdump and readelf show a significant number of bytes in the debug section. What do I look for, more specifically?

---

edit: I expect to see the kind of thing that is on the left of this image, but I see what is on the right:

---

edit2: This does produce embedded source lines in the output of all the files:

%> objdump -Stsxd file0.o > file0.dis
%> objdump -Stsxd file1.o > file1.dis
...
%> objdump -Stsxd fileN.o > fileN.dis

The information IS in the object files. Something about the way I am conducting a separate link is stripping it out...?

I switched to full/absoulte paths for all the object files in my link command. No joy.

---

edit3: My custom linker script, given with -T and mentioned above as script.lds, has a debug section that looks like this:

---

edit4:

By running with NO linker script, or by manually providing the DEFAULT linker script, I get the output I expect.

That shows the problem is my linker script.

By replacing my debug section with all of the debug symbols/sections from the default linker script, it still does not work. It is NOT a missing symbol. There is something else... Hmmm...

Here is the debug sections/symbols from the default linker script:

---

edit5: Experiments suggested here showed that the problem was caused by the linker script. Adding sections that were in the default linker script, but not mine, was a good idea. It didn't fix it, but it was the right thing to do.

I did some cleanup, additions and deletions in the linker script, and it started working!

I cannot pinpoint what, exactly the problem was, and I realize how frustrating it is that I cannot post the full linker script...

Answer 1

This worked correctly for me without a linker script, so the issue is in the linker script.

Your custom linker script has an error in its format or a bug that is removing the source.

You can't share the linker script, per employer prohibition. So you should compare the default linker script and your linker script for any missing or changed elements.