3 ms·

Frame pointers are old-school technology for most of the platforms, even in embedded usage. The libunwind library should be used instead, with the -funwind-tabl

by pajko 3y ago

Frame pointers are old-school technology for most of the platforms, even in embedded usage. The libunwind library should be used instead, with the -funwind-tables or -fasynchronous-unwind-tables compiler options and additionally -rdynamic, -fno-dwarf2-cfi-asm, -fvar-tracking-assignments.

rwmj 3y ago
That's a nice theory but it doesn't actually work in practice. Read the link I posted above.
mgaunard 3y ago
-rdynamic isn't going to help libunwind, it's for glibc's built-in backtrace library which you simply shouldn't use. var-tracking-assignments in on by default when you use any variant of -g (which you should). You can also configure the targeted dwarf version there (which by default is 5 these days) and the level of debugging info, which you should set to the max. This makes your dwarf2-related options redundant. -funwind-tables is also there by default in C++, not sure for C.
- wahern 3y ago
  > -rdynamic isn't going to help libunwind, it's for glibc's built-in backtrace library which you simply shouldn't use. -rdynamic exports global symbols from the main binary so that they're available to satisfy dependencies of dynamically linked libraries and modules. For example, a Perl or Lua interpreter, or an Apache daemon, will use -rdynamic so that its symbols can satisfy the dependencies of binary modules, rather than requiring the engine implementation to be linked via a shared library itself, which is more brittle. It's sort of midway between static and dynamic linking in terms of ensuring everybody is using the same implementation of a shared framework.
nemetroid 3y ago
Frame pointers are making a resurgence for use cases where you want to unwind the stack really quickly, and Dwarf based options are too slow.
- PhilipRoman 3y ago
  Maybe I'm missing something but isn't it redundant to have both stack and frame pointers? Just use negative offsets from the frame pointer to address local variables.

by pajko 3y ago

rwmj 3y ago

That's a nice theory but it doesn't actually work in practice. Read the link I posted above.

mgaunard 3y ago

-rdynamic isn't going to help libunwind, it's for glibc's built-in backtrace library which you simply shouldn't use. var-tracking-assignments in on by default when you use any variant of -g (which you should). You can also configure the targeted dwarf version there (which by default is 5 these days) and the level of debugging info, which you should set to the max. This makes your dwarf2-related options redundant. -funwind-tables is also there by default in C++, not sure for C.

wahern 3y ago
> -rdynamic isn't going to help libunwind, it's for glibc's built-in backtrace library which you simply shouldn't use. -rdynamic exports global symbols from the main binary so that they're available to satisfy dependencies of dynamically linked libraries and modules. For example, a Perl or Lua interpreter, or an Apache daemon, will use -rdynamic so that its symbols can satisfy the dependencies of binary modules, rather than requiring the engine implementation to be linked via a shared library itself, which is more brittle. It's sort of midway between static and dynamic linking in terms of ensuring everybody is using the same implementation of a shared framework.

nemetroid 3y ago

Frame pointers are making a resurgence for use cases where you want to unwind the stack really quickly, and Dwarf based options are too slow.

PhilipRoman 3y ago
Maybe I'm missing something but isn't it redundant to have both stack and frame pointers? Just use negative offsets from the frame pointer to address local variables.