>>>(gdb) bt
>>>#0 0x281330a1 in bn_mul_add_words () from ./libcrypto.so.0.9.8
>>>(gdb) info r
>>>eax 0x30281d48 807935304
>>>(gdb) disassemble
>>>Dump of assembler code for function bn_mul_add_words:
>>>0x28133090 : call 0x28133095
>>>0x28133095 : pop %eax
>>>0x28133096 : add $0x163630,%eax
>>>0x2813309b : mov 0x2cc(%eax),%eax
>>>0x281330a1 : btl $0x1a,(%eax)

>>
>>btl? This most likely indicates bug in binutils or run-time linker, as
>>it's ld, which is solely responsible for constants above btl and
>>run-time linker is responsible for value found at 0x2cc(%eax) location.

>
> How can I check it?


Check what? Is it ld or run-time linker? I don't know... Though note the
constant added to %eax [3rd line]. It's added to the address of *above*
instruction, pop %eax to be specific, to produce the address of
GLOBAL_OFFSET_TABLE. Now, given the address of pop instructions and
constant value the address would end with ... 5, right? I find it very
hard to beleive that the table in question would be unaligned. Meaning
that run-time linker is unlikely one to blaim. ld is likely to be buggy.
Though it also might be bug in assembler, which records wrong bias into
..o file, which is then processed by linker... What do you see there if
you objdump -d crypto/bn/bn86-elf.o? You should see 'add $2,%eax' in .o
which is not yet linked.... But both ld and as are part of binutils, so
just try newer binutils... A.

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org