>>>(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 <bn_mul_add_words+32>: call 0x28133095 >>><bn_mul_add_words+37> >>>0x28133095 <bn_mul_add_words+37>: pop %eax >>>0x28133096 <bn_mul_add_words+38>: add $0x163630,%eax >>>0x2813309b <bn_mul_add_words+43>: mov 0x2cc(%eax),%eax >>>0x281330a1 <bn_mul_add_words+49>: 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 [EMAIL PROTECTED]
