This is the mail archive of the
mailing list for the binutils project.
Re: assemble code and disassembled code in-consistency
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Feng LI <nemokingdom at gmail dot com>, Mark dot Charney at intel dot com
- Cc: Binutils <binutils at sourceware dot org>, "H. Peter Anvin" <hpa at zytor dot com>, Andi Kleen <andi at firstfloor dot org>
- Date: Fri, 6 Jul 2012 09:54:23 -0700
- Subject: Re: assemble code and disassembled code in-consistency
- References: <CAPekQOruy3zHAj7yLKGhyWJrKabhd_AC=eUJSx9gXy91fXUVfw@mail.gmail.com> <CAMe9rOrJffJH8FTd1aorfuWQRkD5hn_o4v4Yn3xiOBc2-tJHPg@mail.gmail.com>
On Fri, Jul 6, 2012 at 9:47 AM, H.J. Lu <email@example.com> wrote:
> On Fri, Jul 6, 2012 at 9:27 AM, Feng LI <firstname.lastname@example.org> wrote:
>> Hi folks,
>> I have a backend hook (x86_64) for builtin function expansion, so
>> I have this:
>> expand_simple_binop (DImode, ASHIFT, op0,
>> GEN_INT (32),op0,1,OPTAB_DIRECT);
>> to generate op0 = op0<<32 (op0 is the first argument of this builtin
>> function, with type SIZE_T)
>> The thing goes well in the assemble code, where I got:
>> movq 104(%rbx), %rax
>> salq $32, %rax
>> addq 80(%rbx), %rax
>> as expected.
>> But at execution time, it gives me a strange behavior,
>> So I disassemble the code,
>> 401135: 48 8b 43 68 mov 0x68(%rbx),%rax
>> 401140: 48 c1 e0 20 shl $0x20,%rax
>> 401144: 48 03 43 50 add 0x50(%rbx),%rax
>> and it turns out salq are changed to shl which leads to the
>> strange behavior. shl only allows shift less or equal than 31.
> It is a binutils issue.
Hi Peter, Andi, Mark,
For some reason, binutils encodes sal the same as shl. I'd
like to fix it. Will it cause any problems?