Re: dSYM + atos + bundles
Re: dSYM + atos + bundles
- Subject: Re: dSYM + atos + bundles
- From: Rick Altherr <email@hidden>
- Date: Mon, 11 Aug 2008 10:48:26 -0700
On Aug 11, 2008, at 8:17 AM, James Turner wrote:
I'm having a problem, where atos seems not to be working, despite
documentation (and archived posts to this list) indicating that what
I'm trying should work, at least with Xcode 3.0 or higher. I'll
outline the steps I'm doing, and hopefully someone can spot my
mistake. Note this is all code compiled use make, not Xcode.
There's an additional complication that when I get this working, the
build machine in question is running 10.4 / Xcode 2.5. My perception
is that this should not matter (dsymutil exists there, and I can use
the newer atos on 10.5 regardless), but in any case right now I'm
testing locally on 10.5 / Xcode 3.1 and it still doesn't work.
In case it makes any difference, the bundle in question is a
Netscape-API browser plugin, so the plugin host is Safari, Firefox
or Opera.
====== build steps ==============
1 - compile code (hopefully no surprises here)
g++ -gdwarf-2 -o foo.o foo.cpp
2 - link (again, nothing special expect -bundle)
g++ -o myplugin -bundle ..... object files ......
3 - create dsym archive
dsymutil --out=/some/path/ myplugin
[creates a .dSYM bundle, note this is NOT in the same directory as
either the myplugin object OR its wrapper bundle ... this could be
changed]
4 - strip - note this is the settings I'm using on 10.4, for 10.5 I
use linker flags instead (-Wl,-x -exported_symbols_list my_exported-
symbols) instead, end result is the same
strip -u -s my_exported_symbols_list myplugin
======= end of build steps ==========
now, when I get a crash in my loaded plugin (at the moment, an
artificially induced one, so I know what the line number and back-
trace should look like), the crash report log has something like:
0 myplugin 0x1fe311f1 main + 121201
1 myplugin 0x1fe489ac main + 217388
2 myplugin 0x1ff5b1a2 main + 1341730
3 myplugin 0x1ffdeb28 main + 1880744
('main' is one of the four symbols exported by the plugin, I know
that might seem odd but it's a FF2 twist and unrelated to my woes)
And here's where it all goes wrong: I'd expect to be able to run
'atos' (Xcode 3.0 version) like this:
(note, slide value from the crash report is 0x1fe00000 for 'myplugin')
atos -o /path/to/my.dSYM/Contents/Resources/DWARF/myplugin -s
0x1fe00000 0x1fe311f1
You don't point atos to the .dSYM. The .dSYM only contains the DWARF
info. It doesn't have a symbol table, etc.
and get a source code fine and line number. But I don't, I just get
the 'unslid' address.
I also tried using a plugin binary as the atos input, and ensuring
the .dSYM bundle was in the same directory as the plugin bundle, but
all to no avail.
The correct placement for a dSYM is in the same directory as the
bundle or executable.
I guess I've missed something about how this is meant to work. Is
atos just spectacularly picky about the structure and placement of
the original executable and bundle, and the .dSYM bundle? If so,
what is the correct arrangement for something like a browser plugin?
Archiving the stripped plugin bundle alongside the .dSYM would be
fine, but on my local machine I can't seem to find any combination
that actually works.
Last I knew, there was a bug in Xcode 3.0's framework that atos uses
such that symbol names are not loaded from the dSYM. I believe that
was resolved in Xcode 3.1, but I can't say for certain.
Or is there some funny interaction with strip / strip options passed
to ld?
Well, you've stripped the symbol names from the binary. The dSYM
contains the DWARF information, which includes the symbol names and
source line information, but there was a bug where the symbol names
are not collected from the dSYM. If you don't strip the binary, it
will show the symbols just fine.
Cheers,
James
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
--
Rick Altherr
Architecture and Performance Group
email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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