EmbDev.net

Forum: ARM programming with GCC/GNU tools Yagarto - crash in objdump (well, almost)


von Dan M. (gorlash)


Rate this post
0 useful
not useful
After the discussions that I had in previous messages here (about
different GnuArm  versions), I tried installing Yagarto (gcc 4.2.2) and
building my project with that.  The compiling and linking went
successfully, but the last step in my makefile is to generate a listfile
with:

arm-elf-objdump.exe -h -S odu.elf > odu.lst

With GnuArm (gcc 4.1.1) objdump, this process takes about 5 seconds to
finish, with a 731KB .elf file (generated by Yagarto).  The .lst file
size is 2.7 MBytes.

With Yagarto objdump run against the same .elf file, I thought objdump
had hung, with cpu utilization stuck at 100% (on an Athlon 64 2200+ and
2.5 GB RAM).  However, eventually after a little over 2 minutes, it
did finish, having generated 1.9 MByte .lst file (much smaller than
what GnuArm output).  This looks like a bug in objdump ??

I'm holding off on attaching any files, until someone indicates what
would be useful to them.  All these files are pretty large...

von Dan M. (gorlash)


Rate this post
0 useful
not useful
Also, I notice that Yagarto did not include the C/ASM source code in
the listing, as GnuArm did.  This makes comparison of the lst files
someone difficult.

von Martin T. (mthomas) (Moderator)


Rate this post
0 useful
not useful
Dan Miller wrote:
> Also, I notice that Yagarto did not include the C/ASM source code in
> the listing, as GnuArm did.  This makes comparison of the lst files
> someone difficult.

This may be caused by a bug in objdump when source-code with DOS
file-endings (\r\n) should be "intermixed" with the assembly. I have
reported the bug and submitted a fix to the binutils-project. Issue
should be fixed in the next binutils-release an binaries based on this
code. Possible solutions:
- convert you source-code to unix line-endings (\n only)
- replace objdump.exe with one compiled from older binutils sources
- compile your own objdump.exe from current binutils CVS code
- try with objdump.exe from WinARM-testing 3/2008

The increase in runtime may be caused by the "source-file-caching"
introduced in newer versions of the binutils objdump but so far I have
not seen such a huge increase in runtime.

EDIT: it may be cause by the DOS-lineending error too since the
buggy-objdump tries to read the source-code over and over again and
fails. The "possible solutions" mentioned above should fix this too
since objdump can read every souce-file just once successfully.

von Dan M. (gorlash)


Rate this post
0 useful
not useful
Martin Thomas wrote:
> This may be caused by a bug in objdump when source-code with DOS
> file-endings (\r\n) should be "intermixed" with the assembly.

Ahhh!!  indeed, I ran dos2unix against all .c and .s files, and both of
these problems went away... that's a fine solution for me, for now.
Thanks!!

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.