On 2010-07-02, JMGross <msp...@grossibaer.de> wrote:
> Von: N. Coesel
> Gesendet am: 01 Jul 2010 14:19:57
>
>>> I too use objdump to generate a complete project listing from the elf
>>> file.
I've never seen that work except for extremely trivial programs.
>>> It has, however, some serious drawbacks.
As in "it doesn't work?" :)
>>> Not only that jumps and calls are not printed with their symbolic
>>> name, also the source code in the listing is sometimes (often) from a
>>> completely different file or from different lines of the same file.
>>> So it is virtually useless.
>
>>AFAIK this is the result of compiling with optimisation on. If you
>>want a proper list file with source code mixed in, you should compile
>>without optimisation (-O0) and with full debugging enabled (IIRC -g3).
>>At least thats how it works for me when using GCC in general.
>
> No, its not an optimization problem. The individual .lst files of the
> object files are fine. Sometimes, the source is a bit mangled by
> optimization, (and sometimes, the assembler will show som boguse
> unreachable code warnings too due to optimization, but in general it
> fits. At least the source is form the same function. But in the
> global .lst file that objdump generates, the source code is a real
> mess.
Generating source listings from a linked program using objdump has
never worked for any target architecture I've tried. IMO, you're
beating your head against the wall trying to generate source listings
with objdump.
Generating them for individual files by passing appropriate flags to
the assembler has always worked on all the architectures I've used
(though I can't vouce for gcc 4.x on the '430, it works fine with
3.x).
> I can't find a pattern too. Sometimes the source code is okay,
> somethimes it is a completely different part of the right file,
> sometimes it is from a completely different source file not related
> to the code at all.
That's the behaivior I've always seen when trying to generate source
listings using objdump.
> If I switch on some more info in the global .lst, the comments show
> 'File a, line x' yet the source code is from file b, line x or even
> line y. So the info is there (File a line x would be correct). Even
> the path of file a is shown correctly (so using VPATH is not
> aproblem) But then somehow things get messed up. Seems that objdump
> is unable to extract line x in file a and extracts line y from file b
> instead.
Based on how completly it's broken and how long it's been that way, I
assumed that it wasn't supposed to work...
--
Grant Edwards grant.b.edwards Yow! I have accepted
at Provolone into my life!
gmail.com
