>
>> 4. Does anyone have any pointers on what kind of workflow is
>> necessary to interpret user-submitted crash reports when using dwarf-
>> with-dsym? I know how to use atos on an unstripped binary that
>> contains STABS-format debugging information. But I have no idea at
>> all what the paradigm is with dsym files.
>
> Unfortunately this is a hole in the XCode 2.3 workflow - it's
> something we'll need to address in a future release. You would run
> atos on the dSYM file but currently atos can't parse that file. You
> may be able to jury-rig gdb to do what you need -- gdb being one of
> the few utilities on the system that understand dSYM files right now.
I hasn't gotten around to asking this question yet, so I'm glad someone
did... and wow...
So, basically, the only (real) option for us folks here is still use stabs
for release builds (sorry, I don't consider *any* 'jury-rig' to be part of
an acceptable workflow). As I'm sure is w/ a lot of people here, being
able to easily turn a crash report into a symbol-stack is a pretty important
thing for a developer to be able to do.
For example, when we do closed betas, we pack our binary w/ symbols so that
crash reports that come in have symbols in the stack trace. This allows us
to evaluate a crash report in about 15 seconds.
In any case, I'm sure most ppl here agree that it sure would be nice to get
dSYM support moved to other parts of the OS asap. Or, alternatively, apple
make a atos enhancement that take a crash report file and a dSYM file and
does the necessary parsing and symbol lookups so it can poop out a stack
trace w/ symbols and line numbers. Any hints on how far this is away??
andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
This email sent to email@hidden
