Re: assemble code and disassembled code in-consistency

[Mark Charney <mark dot charney at intel dot com>]

On 7/6/12 12:54 PM, H.J. Lu wrote:
> On Fri, Jul 6, 2012 at 9:47 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Fri, Jul 6, 2012 at 9:27 AM, Feng LI <nemokingdom@gmail.com> 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?
>
> Thanks.

SAL = SHL functionally. They are aliases. FWIW, XED
does not even have SAL; I call them all SHL.