lldb and "fake" dsym on Mac

[Jiang Jiang]

Hi,

I'm currently trying to debug Release builds built on my own
Mac OS X without "mac_strip_release=0" in my GYP_DEFINES, as
I understand it's possible with all the dSYM bundles generated
by build/mac/strip_save_dsym.

According to this script:

# Rationale: the "right" way to generate dSYM bundles, dsymutil, is incredibly
# slow. On the other hand, doing a file copy (which is really all that
# dsymutil does) is comparatively fast. Since we usually just want to strip
# a release-mode executable but still be able to debug it, and we don't care
# so much about generating a hermetic dSYM bundle, we'll prefer the file copy.
# If a real dSYM is ever needed, it's still possible to create one by running
# dsymutil and pointing it at the original Mach-O file inside the "fake"
# bundle, provided that the object files are available.

I took that if I have all the .o files at the original location,
with this "fake" dSYM I should be able to get line number
information and such, is that correct?

build/common.gypi claim that this is a faster way than using
dsymutil ("mac_want_real_dsym=1"), indeed, but when debugging
with lldb, I can't get the line number information and link to
source code, I can set breakpoints to certain symbols
(ContentMain for instance) but all I got is just the address.

In lldb I tried "image list" command and it does show:

[ 0] 4CA2FA10-26F0-30D6-BECB-D472028A8C39 0x00001000
../chromium/src/out/Release/<AppName>.app/Contents/MacOS/<AppName>
../chromium/src/out/Release/<AppName>.app.dSYM/Contents/Resources/DWARF/<AppName>
...
[ 30] 46CB38B8-A3E6-3528-BD8B-B2D403F861F8 0x00004000
/Users/jjgod/work/chromium/src/out/Release/<AppName>.app/Contents/Versions/<Version>/<AppName>
Framework.framework/<AppName> Framework
/Users/jjgod/work/chromium/src/out/Release/<AppName>
Framework.framework.dSYM/Contents/Resources/DWARF/<AppName> Framework

With mac_want_real_dsym=1 I can debug with lldb and get such
line number and source code file path information.

I have tried both with "component=shared_library" and without,
got the same problem.

I have also tried using gdb but the results are the same.

If it's relevant, our source code is outside of chromium/src
because it's a separate application using content API but with
similar bundle organizations as Chromium.app.

- Jiang

[Nico Weber]

Does it work with gdb?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Jiang Jiang]

On Fri, Mar 15, 2013 at 6:16 PM, Nico Weber <tha...@chromium.org> wrote:
> Does it work with gdb?

Nope.

I wonder if there is any possible way to diagnose this, either with
gdb or lldb, or with other tools such as dwarfdump.

- Jiang