On Mar 25, 2015, at 2:42 PM, Matt Cross <[email protected]> wrote: > 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.
I think the cfi_cfa_indirect pseudo-directive handles that case (it’s defined in x86gas.pl and used in, e.g., aesni-x86, which does a similar stack alignment). It uses a minuscule “assembler” for DWARF location opcode expressions included in the 3-cfi patch, which makes it easier to handle cases where the assembly is doing something clever. The SHA256 and SHA512 implementations on x86_32 did something trickier: each round adjusted the stack frame forwards by some number of bytes, so that it could read the previous round and write the new data from fixed offsets from $esp (presumably this saves a register). I didn’t try writing DWARF info to unwind that. I don’t think the x86_64 code does that, though, since registers aren’t as scarce. > If I understand correctly, your patch was not folded in. Do you recall why? IIRC, the maintainer said it would be too much trouble to integrate. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
