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:
cfi-fpo-3.patch
Description: Binary data
