[openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Matt Cross]

On Wed, Mar 25, 2015 at 3:19 PM, Wim Lewis <wiml at omnigroup.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150325/5fa15004/attachment.html>