Re: Extract information from Mac OS X crashlog
Re: Extract information from Mac OS X crashlog
- Subject: Re: Extract information from Mac OS X crashlog
- From: Kevin Molcard <email@hidden>
- Date: Mon, 30 Sep 2013 13:42:50 +0200
Hi Jim,
thanks a lot for the explanation, it gives me lots of useful information.
It seems that the problem is that Xcode is stripping the static library
before the creation of the dSYM file.
Since this static library is only for internal use I think I can safely
not strip it and only strip the application.
Kevin
On 9/26/13 7:38 PM, email@hidden wrote:
The static library has to be built into some binary image (dylib or executable) to be useful. What's probably happening is that the debug information is getting lost between building the .a file and making the dSYM for the dylib that uses the .a file.
The way debug information is handled in Mac OS X is that the debug information always stays in .o files, and the Mac OS X linker writes a "debug map" into any linked product that will point back to the .o files. Then you build a dSYM with the dsymutil tool. It looks at this "debug map" and follows it to the .o files, extracts the DWARF and links it all up into the dSYM.
.a files are not a product of the linker, they are just a bag of .o files. So they normally work fine in this process: the ar tool copies the .o files with their DWARF into the .a file, and the linker generated debug map points back to the .o file within the .a file, and dsymutil grubs around in the .a file to extract the relevant DWARF.
But for instance, if you deleted the .a file after the link but before you built the dSYM, then there would be no debug info from that .a file.
The other thing to note is that among the things the "strip" tool removes from a binary is the debug map. So you have to be careful in your build process that you don't strip any of the build products until AFTER you make the dSYM. If you don't get that right then you will have some parts of your executable that will not have any debug info.
Another problem is if you use the "ld -r" command to produce a "partially linked .o file". Since that is made by the linker, it does NOT copy the debug info into the resultant partially linked .o file, it writes a debug map instead. So in order for dsymutil to find the debug info, both the initial .o files and the "ld -r" output .o file have to remain in place and unstripped.
Hopefully this little sketch of how things work will help you identify where the debug info is getting dropped when you build a stripped executable.
Jim
On Sep 26, 2013, at 9:08 AM, Kevin Molcard <email@hidden> wrote:
Unfortunately I get the same result by setting manually the dSYM file.
After some more investigation, it seems that it is because I use a static library.
If I got a crash in a file that is compiled in the application target I can get the line number.
However if the crash is occuring in a file that is from the static library I always get the "No line number information available for address" message.
If I am not wrong, the static library is not position-independent code so the slide is 0 (right?).
Should I use some particular flags in the static library target?
Kevin
On 9/26/13 8:39 AM, Kevin Molcard wrote:
Hi,
thanks for the information, I will read your document and do some tests.
I was not aware of the add-dsym command. I was putting the dSYM file in the same directory than my app.
Kevin
On 9/25/13 5:37 PM, Jerry Krinock wrote:
On 2013 Sep 25, at 00:45, Kevin Molcard <email@hidden> wrote:
Unfortunately, once I have stripped symbols, no matter the value of the|STRIP_STYLE|flag, the product I am not able to get the exact line number. From what I read in the TN, it seems to be possible.
The procedure given in TN2123 assumes that gdb will find the dSYM with Spotlight, which doesn't always work. To fix that, give it your dSYM manually using the add-dsym command.
For exact details, and other tips I've collected which are not in TN2123, read this…
https://gist.github.com/jerrykrinock/6701316
_______________________________________________
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
--
Kevin Molcard
Sofware Engineer
ARTURIA
30, chemin du Vieux Chene
38240 Meylan - France
Tel: +33 438 020 555
Fax: +33 438 020 525
http://www.arturia.com
_______________________________________________
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
--
Kevin Molcard
Sofware Engineer
ARTURIA
30, chemin du Vieux Chene
38240 Meylan - France
Tel: +33 438 020 555
Fax: +33 438 020 525
http://www.arturia.com
_______________________________________________
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