Fwd: [PATCH] cfi/fpo directives in md5 assembly code

2011-07-13 Thread yoni londner
So, how can we promote this patch to be commited? It is recommended to register the request on request traker at http://www.openssl.org/support/rt.html Ok. I sent an email to r...@openssl.org Thanks Gilles Yoni. __ OpenSSL

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-07-12 Thread Gilles Espinasse
Selon yoni londner jon...@gmail.com: So, how can we promote this patch to be commited? It is recommended to register the request on request traker at http://www.openssl.org/support/rt.html Give as much as you can details on how to use the change, which source tree is patched. Eventually

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-07-08 Thread Wim Lewis
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

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-30 Thread yoni londner
I wasn't proposing that the other changes had to be done now --- just noting that the lack of unwind information seems to be a problem that most of the assembly files have. I think the extra registers' unwind info for the md5 asm is worth including now, though, since it's a tiny enhancement.

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-29 Thread yoni londner
I agree entirely, but why not fix the other registers while we're at it? I've attached a version of your diff with the extra registers' unwind info added--- untested, unfortunately--- it'll also need a sub ::cfi_restore { ::emit(.cfi_restore,@_); } in x86gas.pl and the corresponding stub

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-29 Thread Wim Lewis
On 28 Jun 2011, at 5:56 PM, Wim Lewis wrote: Several of the other assembly files could use the same treatment as well: md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses %ebp as a scratch register, etc. It occurs to me that a lot of the CFI management could be done

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-28 Thread yoni londner
On Mon, Jun 27, 2011 at 22:20, Wim Lewis w...@omnigroup.com wrote: On 27 Jun 2011, at 9:27 AM, yoni londner wrote: As you know, on 32bit systems, when using EBP for anything other than holding the stack base, it is very difficult to get reasonable backtrace. this can be fixed if directing

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-28 Thread Wim Lewis
On 28 Jun 2011, at 12:21 AM, yoni londner wrote: 1. I looked at a generated assembler from gcc. So I am not 100% sure what is the 'most correct', but this is what gcc emits. I was concerned that since this routine isn't compiler-generated it might be doing something different from what

[PATCH] cfi/fpo directives in md5 assembly code

2011-06-27 Thread yoni londner
Hi, As you know, on 32bit systems, when using EBP for anything other than holding the stack base, it is very difficult to get reasonable backtrace. this can be fixed if directing the compiler to add a debug record which tells (at runtime) where we keep EBP value. So, I added this record (FPO in

Re: [PATCH] cfi/fpo directives in md5 assembly code

2011-06-27 Thread Wim Lewis
On 27 Jun 2011, at 9:27 AM, yoni londner wrote: As you know, on 32bit systems, when using EBP for anything other than holding the stack base, it is very difficult to get reasonable backtrace. this can be fixed if directing the compiler to add a debug record which tells (at runtime) where we