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. >> It has, however, some serious drawbacks. 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. 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. 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. JMGross
