objdump -S doesn't include source for all modules

I'm cross-compiling for the SPARC/Leon3 processor under WinXP/msys or WinXP/cygwin, both with the same problem: there are many modules compiled with a Makefile (same CFLAGS for all modules). When disassembling the resulting application with sparc-elf-objdump -dS app > app.dis for some modules the listing includes the source lines, while for other modules it doesn't. When I disassemble separate object files the Source is always included: sparc-elf-objdump -dS module.o > module.dis

So it seems that source-line information is lost during linking ? But only for some modules, not for others ?

I tried to switch off optimization, tried to dos2unix & unix2dos all sources, all with the same result ...

Any ideas are welcome. Thanks & regards, Rolf.

The relevant part of the Makefile: CC = sparc-elf-gcc LD = sparc-elf-ld OBJDUMP = sparc-elf-objdump -dS MKPROM = sparc-elf-mkprom LIB = sparc-elf-ar cr RANLIB = sparc-elf-ranlib

LEON= -mv8 -msoft-float SVT= CFLAGS= -g -O0 -Wall $(LEON) $(DEFS) -Ificl40 -Ileonlib -DBELA_PBS LDFLAGS = -g $(SVT) -Lficl40 -Lleonlib LIBRARIES = $(SVT) -lleon -lficl -lsmall -lc -lm

HEADERS= $(wildcard *.h) SOURCES= $(wildcard *.c) OBJECTS= $(subst .c,.o,$(SOURCES))

pbs: $(HEADERS) $(OBJECTS) $(MYLIBS) $(CC) $(LDFLAGS) -g -Xlinker -Map -Xlinker $@.map $(OBJECTS) -o $@ $(LIBRARIES) -Ttext=$(PROM_SW_ADDR) $(OBJDUMP) $@ > $@.dis

Reply to
Rolf Schroedter
Loading thread data ...

Seems to me, that newer binutils even more broken than older binutils. I tested sparc-rtems-objdump (version 2.18) vs. sparc-elf-objdump (version 2.16.1).

sparc-elf-objdump -dS -l (version 2.16.1)

------------------------------------------ Same behavior for dos2unix & unix2dos sources:

- All object (module) disassembler files are correct.

- The executable (application) disassembly shows the C-source of some modules, for other modules it doesn't

- AFAIS same modules show/don't show for dos2unix & unix2dos C-sources.

- AFAIS (as far as I see) line numbers (objdump -l) for all modules are correct.

sparc-rtems-objdump -dS -l (version 2.18)

------------------------------------------- unix2dos sources:

- All object disassembler files show correct filenames & line numbers, but *no sources*

- The executable disassembly also shows correct filenames & line numbers, but *no C-sources*

dos2unix sources: (!!!)

- All object disassembler files show correct line information, and

*correct sources*

- AFAIS the executable disassembly shows correct filenames and line numbers.

- For some modules the C-source is not shown

- For other modules the C-source is shown correctly

- For other modules the C-source is shown from *an invalid file, same line number* (!!!) (see below: main() is defined in main.c:419, not in memory)

Disassembly of executable/memory module:

---------------------------------------- ... D:\Projekt\Bela\prog\pbs-1/memory.c:419 int main(void) {

41803a84: 82 10 20 02 mov 2, %g1 ! 2 41803a88: c2 27 bf f0 st %g1, [ %fp + -16 ] 41803a8c: 10 80 00 23 b 41803b18 41803a90: 01 00 00 00 nop D:\Projekt\Bela\prog\pbs-1/memory.c:421
Reply to
Rolf Schroedter

Rolf

I'd post this to the binutils newsgroup: you are more likely to get a result there.

Andrew

Reply to
Andrew Jackson

I've never found objdump to be able to reliably and usefully intersperse source code into a dissassembly listing. You're far better off creating the mixed-language listing at compile time by using a makefile rule something like this:

%.o: %.c $(GCC) $(CFLAGS) $(INCLUDES) -c $< -o $@ -Wa,-ahldn=$(@F).l

The "-Wa..." bit at the end is what creates the mixed-mode listing.

--
Grant Edwards                   grante             Yow! ... My pants just went
                                  at               on a wild rampage through a
                               visi.com            Long Island Bowling Alley!!
Reply to
Grant Edwards

Thanks a lot, I wasn't aware about -Wa.

But getting a disassembly of a single C-module also seems to work fine with objdump. What I need is a disassembly of the complete (linked) target image. And this seems to be impossible with objdump -dS ...

Grant Edwards wrote, >

Reply to
Rolf Schroedter

It varies. It works OK for some targets, for some source files, and for some combinations of compiler flags.

In my experience, you are correct -- objdump isn't capable of that. I've never had a need for a global listing like that, so I'm afraid I can't be of much help.

--
Grant Edwards                   grante             Yow! Somewhere in Tenafly,
                                  at               New Jersey, a chiropractor
                               visi.com            is viewing "Leave it to
                                                   Beaver"!
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.