[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/20244] ld fails to handle "op $imm, address@hidden"
From: |
bugs at moronic dot technology |
Subject: |
[Bug ld/20244] ld fails to handle "op $imm, address@hidden" |
Date: |
Wed, 15 Feb 2017 11:03:55 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=20244
--- Comment #13 from Dopıng <bugs at moronic dot technology> ---
My assembler knowledge is rusty, that much is certain...
Excerpts from the output of “objdump -dwr lxecg2e.o”:
00000010 <lxecg2e>:
10: 66 90 xchg %ax,%ax
12: 53 push %ebx
13: 8b dc mov %esp,%ebx
15: 83 e4 f0 and $0xfffffff0,%esp
18: 55 push %ebp
19: 55 push %ebp
1a: 8b 6b 04 mov 0x4(%ebx),%ebp
1d: 89 6c 24 04 mov %ebp,0x4(%esp)
21: 8b ec mov %esp,%ebp
23: 81 ec 08 04 00 00 sub $0x408,%esp
29: 89 9d f8 fb ff ff mov %ebx,-0x408(%ebp)
2f: 89 7d f8 mov %edi,-0x8(%ebp)
32: e8 00 00 00 00 call 37 <lxecg2e+0x27>
37: 5f pop %edi
38: 8d bf 03 00 00 00 lea 0x3(%edi),%edi 3a: R_386_GOTPC
_GLOBAL_OFFSET_TABLE_
3e: 8b 53 08 mov 0x8(%ebx),%edx
41: 89 75 fc mov %esi,-0x4(%ebp)
44: 8d 75 e0 lea -0x20(%ebp),%esi
47: 89 75 f4 mov %esi,-0xc(%ebp)
4a: 0f b7 42 30 movzwl 0x30(%edx),%eax
4e: 85 c0 test %eax,%eax
50: 8b 8f 00 00 00 00 mov 0x0(%edi),%ecx 52: R_386_GOT32 lxetbn
56: 8b 0c 81 mov (%ecx,%eax,4),%ecx
59: 89 4d f0 mov %ecx,-0x10(%ebp)
5c: 75 19 jne 77 <lxecg2e+0x67>
[...]
76: c3 ret
77: 8b 43 18 mov 0x18(%ebx),%eax
7a: 8d b5 08 fc ff ff lea -0x3f8(%ebp),%esi
80: 68 1c 02 00 00 push $0x21c
85: 52 push %edx
86: 56 push %esi
87: c7 00 ff ff ff ff movl $0xffffffff,(%eax)
8d: 8b df mov %edi,%ebx
8f: e8 fc ff ff ff call 90 <lxecg2e+0x80> 90: R_386_PLT32
_intel_fast_memcpy
94: 8b 9d f8 fb ff ff mov -0x408(%ebp),%ebx
9a: 8b 53 1c mov 0x1c(%ebx),%edx
9d: 33 c0 xor %eax,%eax
9f: 52 push %edx
a0: 66 89 85 38 fc ff ff mov %ax,-0x3c8(%ebp)
a7: 8d 85 2c ff ff ff lea -0xd4(%ebp),%eax
ad: 8b 0a mov (%edx),%ecx
af: 8d 15 00 00 00 00 lea 0x0,%edx b1: R_386_GOT32 lxecerr
[...]
That last line is the only reference to ‘lxecerr’. If the JNE at 5c only jumps
in case of an error condition, the remaining code may never get executed. But
that’s quite a lot of code up to 8b4 (including six setjmp() calls, but no
longjmp() call, so this code doesn’t smell like an error handler IMHO).
“ar x libnls12.a ; objdump -dwr *.o | egrep 'lea.*R_386_GOT32' | wc -l” prints
439. Does that grep make sense or would I need to grep for something else? How
would the correct lea instruction look like?
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/14
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden",
bugs at moronic dot technology <=
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/15
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/15
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", bugs at moronic dot technology, 2017/02/15
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/15
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", cvs-commit at gcc dot gnu.org, 2017/02/15
- [Bug ld/20244] ld fails to handle "op $imm, address@hidden", hjl.tools at gmail dot com, 2017/02/17