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...
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.
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.
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!!
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.