On Wed, Mar 25, 2015 at 3:19 PM, Wim Lewis <[email protected]> wrote:
> > > FYI, I submitted a patch a few years ago to do this for many of the x86-32 > assembly files. The perlasm preprocessor already tries to track the stack > offset, which means that a lot of those .cfi directives can be generated > automatically, without requiring the programmer to keep track of them. > > The patches are here: > http://rt.openssl.org/Ticket/Display.html?id=2562 > > As you point out, this is pretty useful to allow profiling and/or > debugging code that spends a lot of its time in OpenSSL. > That's an interesting approach, much more maintainable going forward. As you noted in your bug report, there is some code in the sha1 implementation that does something like this: mov %rsp,%rax and $-64,%rsp mov %rax,64(%rsp) [more code that trashes rax] Then, in the epilogue it does something like this: mov 64(%rsp),%rsi [restore callee-saved variables] mov %rsi,%rsp This is done to align %rsp to a 64 byte boundary, and the original %rsp is stored on the stack; so the only way to get the actual frame pointer is to read 64(%rsp) and add an offset to that. I managed to do that by inserting a raw DWARF expression. It's not clear to me that the perlasm preprocessor could (or should) do this; but perhaps it makes sense to add some directives for the perlasm preprocessor and let it generate the raw DWARF expression. If I understand correctly, your patch was not folded in. Do you recall why? -Matt
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
