Re: Dwarf and comparing binaries
Re: Dwarf and comparing binaries
- Subject: Re: Dwarf and comparing binaries
- From: Jonas Maebe <email@hidden>
- Date: Mon, 26 Nov 2007 12:24:22 +0000
On 25 Nov 2007, at 23:06, Peter O'Gorman wrote:
Jonas Maebe wrote:
Note that I'm not using gcc, as our compiler is self-hosting. Unlike
gcc, it does not use random filenames for intermediate files, so
those
already always have the same name and are always stored in the same
location (the latter because the makefile places them in the same
location every time).
Yeah, the above worked for my (probably too simple) test. I can only
suggest that you build as normal, then for the comparison stage, copy
what is to be compared and run:
strip -S -arch all -no_uuid
on the copied files, then compare the copies.
Great idea, silly that I never thought about doing this myself.
Unfortunately, that does not work either due to apparent bugs in strip
(or ld, although I've never seen such a message from gdb or otool) :/
On 10.4 with Xcode 2.5 for a ppc32 binary:
strip: bad string index for symbol table entry 34 in: /afs/
elis.ugent.be/usr/jmaebe/private/nobackup/fpc/compiler/ppc1
And on 10.5, a stripped x86_64 compiler enters an endless loop (while
it works fine both unstripped and when letting the linker handle the
stripping; it's also independent of whether or not the binary is
compiled with debug info). One more radar coming up...
It does work fine for i386 on 10.5 however, so the principle is ok
(but we still support 10.4, so I can't add this to the makefile, and I
guess no further updates to Xcode for 10.4 will be shipped anymore).
You could also inspect the linker sources at:
http://www.opensource.apple.com/darwinsource/10.5/ld64-77/src
Yes, I already submitted two patches for it via radar :) I just hoped
I could be lazy and get an asy answer here (which I got from you with
the strip stuff, but alas...)
And, since gcc also does comparison of output at various stages of the
build, for similar purposes, you could check what they are doing.
They appear to be comparing the individual object files (skipping the
first 16 bytes) rather than the linked library. That may indeed be
another solution.
Thanks for the input!
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden