EmbDev.net

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


Author: Dan Miller (gorlash)
Posted on:

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...

Author: Dan Miller (gorlash)
Posted on:

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.

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

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.

Author: Dan Miller (gorlash)
Posted on:

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.