So, how can we promote this patch to be commited? On Fri, Jul 8, 2011 at 09:45, Wim Lewis <w...@omnigroup.com> wrote:
> Well, I did some testing with the slightly-modified patch (debian squeeze > and openbsd 4.9), and confirmed that this produces an .eh_frame which allows > gdb to walk the stack successfully if the program is stopped in or > singlestepped through md5_block_asm_data_order(). Some notes, though: > > - Not all versions of gas have the .cfi_foo directives. In fact, > .cfi_sections only showed up in 2.21, and the other directives used here > were added in 2.15. Debian's reasonably up-to-date, but OBSD4.9 has 2.15, > and Apple's dev tools ship with a decade-old 1.x version of gas. So the > config script will presumably need to be able to partially or completely > disable CFI generation. On the bright side, the .cfi_sections directive > isn't actually needed; the default behavior (generating eh_frame but not > debug_frame) is appropriate. > > - x86nasm.pl needed stubs for these directives as well. I have no idea > what NASM supports in this area so I made both the CFI and FPO directives > no-ops. > > - OpenSSL compiles with -fomit-frame-pointer on both of these machines, > which means even the gcc-generated code is not backtraceable unless you add > -funwind-tables. IMHO, the config script should add -funwind-tables unless > disk space is at a premium (it doesn't affect the generated code) --- > unwindability is handy to have. And by the same token, if the C code is > compiled with -fomit-frame-pointer but no unwind tables, then it would make > sense to leave the unwind information out of the asm code as well. > > - The perlasm scripts already keep track of the stack depth (to find args > and such), which should make it possible to generate a lot of the CFI > directives automatically. If this patch is accepted I think it's worth > trying to make the perlasm code handle more CFI generation and then fix up > the other frame-pointer-less asm routines as well. > > > Here's the slightly-amended patch: > > >
