1635812 - Consider adding macOS / mach-O support to LUL, for stackwalking without framepointers on macOS

Status: NEW

(Core :: Gecko Profiler, task, P3)

Description

[Markus Stange [:mstange]]

I'm extracting a conversation about using LUL on macOS from bug 1451902.

(In reply to (not currently active) Ted Mielczarek from bug 1451902 comment #3)

(In reply to Markus Stange [:mstange] from bug 1451902 comment #0)

• On Linux, 32 bit and 64 bit, the situation is the same as on Mac: We have
  frame pointers on Nightly but not on Beta or Release. On Beta and Release,
  we use lul for unwinding, which consults unwinding tables in the binary.

Lul does not currently support unwinding with unwinding tables on macOS. It
could be extended to support it but it would be some work.

Is there any particular reason here other than nobody did the work? Mach-O
binaries use the same eh_frame data as ELF binaries, so it doesn't seem like
it'd be that hard to wire this up. Presumably it's just a matter of dealing
with the platform-specific bits?

(In reply to Julian Seward [:jseward] from bug 1451902 comment #4)

(In reply to Ted Mielczarek [:ted.mielczarek] from bug 1451902 comment #3)

Lul does not currently support unwinding with unwinding tables on macOS. It
could be extended to support it but it would be some work.

Is there any particular reason here other than nobody did the work? Mach-O
binaries use the same eh_frame data as ELF binaries, so it doesn't seem like
it'd be that hard to wire this up. Presumably it's just a matter of dealing
with the platform-specific bits?

I think this didn't happen because we've never seriously considered using
LUL to unwind on OSX (until now). It wouldn't be a big deal to write a
Mach-O parser for LUL if we wanted. That would, as Ted implies, find the
relevant Dwarf unwind info sections, which we'd just hand off to LUL as at
present.

However, isn't there some complication in which Mach-O debuginfo is not
linked into .dsym files, but held separately? I seem to remember some
complication with this, and the use of the dsymutil program, as a workaround
from Valgrind-on-OSX days. But I'm not sure of the details and also not
sure if this is actually relevant here.

(In reply to (not currently active) Ted Mielczarek from bug 1451902 comment #5)

You're correct, but thankfully Apple's toolchain does put .eh_frame directly
in the binary itself:

$ objdump --section-headers /Applications/Firefox.app/Contents/MacOS/firefox

/Applications/Firefox.app/Contents/MacOS/firefox: file format
mach-o-x86-64

Sections:
Idx Name Size VMA LMA File off
Algn
0 .text 00000ced 0000000100000cd0 0000000100000cd0 00000cd0
24
CONTENTS, ALLOC, LOAD, CODE
1 __TEXT.__stubs 000000d8 00000001000019be 00000001000019be 000019be
21
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 __TEXT.__stub_helper 00000164 0000000100001a98 0000000100001a98
00001a98 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .cstring 000001c5 0000000100001bfc 0000000100001bfc 00001bfc
20
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 __TEXT.__unwind_info 00000088 0000000100001dc4 0000000100001dc4
00001dc4 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .eh_frame 000001b0 0000000100001e50 0000000100001e50 00001e50
23
CONTENTS, ALLOC, LOAD, READONLY, DATA
<...>

There's also that __unwind_info section which is unwind info in Apple's
"compact unwind encoding":
https://github.com/llvm-mirror/libunwind/blob/master/include/mach-o/
compact_unwind_encoding.h

I've never dug into it but it looks extremely similar to the ARM unwind
tables or the Win64 unwind info.

(In reply to Julian Seward [:jseward] from bug 1451902 comment #6)

(In reply to Ted Mielczarek [:ted.mielczarek] from bug 1451902 comment #5)

There's also that __unwind_info section which is unwind info in Apple's
"compact unwind encoding":

Without looking at it in detail .. I'd guess those could be converted into
LUL's internal unwind records at the point LUL reads the info. So then
it could seamlessly unwind with any mixture of "compact unwind" and
traditional Dwarf CFI. Some time in the past there was a similar scheme
to read ARM32 EXIDX into LUL (it worked, but has since been removed).