llvm dev - Feb 2016 - Fwd: X86 assembler cannot jump NEAR?

> On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> The problem is that llvm-mc always compiles "jmp" this as short
jump, no matter where the target is. Hence my question. I dont know if there is
any way to change this behavior. Looks like a bug to me so far.
It isn't. It's just created some assembly which, when assembled, may end
up as a near jump or a short jump.
> Craig said there is a trick with object file, but I dont know how to do
that. Also, why compiling to object file changes the result?
Here's an object file (although I don't know why it's producing ELF
rather than Mach-o):

$ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 
-filetype=obj > a.o
$ x86_64-pc-elf-objdump -d a.o

a.o:     file format elf32-i386


Disassembly of section .text:

00000000 <.text>:
  0:	e9 fc ff ff ff       	jmp    0x1

And here's assembly which is then run through the compiler.

$ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 
-show-encoding |tee b.s
	.text
	jmp	_label                  # encoding: [0xeb,A]
                                       #   fixup A - offset: 1, value: _label-1,
kind: FK_PCRel_1
$ clang -c b.s
$ otool -tvj b.o
b.o:
(__TEXT,__text) section
0000000000000000	e900000000      	jmp	0x5

As you can see, both produced near jumps. (I assume the difference between the
offsets has to do with a difference in relocations between ELF and Mach-o.)

-- 
Stephen Checkoway

On Feb 28, 2016 12:08 AM, "Stephen Checkoway" <s at pahtak.org>
wrote:
>
>
>
> > On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > The problem is that llvm-mc always compiles "jmp" this as
short jump,
no matter where the target is. Hence my question. I dont know if there is
any way to change this behavior. Looks like a bug to me so
far.
>
> It isn't. It's just created some assembly which, when assembled,
may end
up as a near jump or a short jump.
>
> > Craig said there is a trick with object file, but I dont know how to
do
that. Also, why compiling to object file changes the
result?
>
> Here's an object file (although I don't know why it's producing
ELF
rather than Mach-o):

Oh this is cool! Which code in MC is responsible for replacing EB with E9
when dumping to object file like this???

Thanks.
>
> $ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 
-filetype=obj
> a.o
> $ x86_64-pc-elf-objdump -d a.o
>
> a.o:     file format elf32-i386
>
>
> Disassembly of section .text:
>
> 00000000 <.text>:
>   0:    e9 fc ff ff ff          jmp    0x1
>
> And here's assembly which is then run through the compiler.
>
> $ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 
-show-encoding
|tee b.s
>         .text
>         jmp     _label                  # encoding: [0xeb,A]
>                                        #   fixup A - offset: 1, value:
_label-1, kind: FK_PCRel_1
> $ clang -c b.s
> $ otool -tvj b.o
> b.o:
> (__TEXT,__text) section
> 0000000000000000        e900000000              jmp     0x5
>
> As you can see, both produced near jumps. (I assume the difference
between the offsets has to do with a difference in relocations between ELF
and Mach-o.)
>
> --
> Stephen Checkoway
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160228/4aef472c/attachment.html>

The change is done during relaxation. I think you can search for
fixupNeedsRelaxation if I remember right. I don't have the source code
available on this computer.

On Sat, Feb 27, 2016 at 10:17 AM, Jun Koi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> On Feb 28, 2016 12:08 AM, "Stephen Checkoway" <s at
pahtak.org> wrote:
> >
> >
> >
> > > On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > > The problem is that llvm-mc always compiles "jmp" this
as short jump,
> no matter where the target is. Hence my question. I dont know if there is
> any way to change this behavior. Looks like a bug to me so far.
> >
> > It isn't. It's just created some assembly which, when
assembled, may end
> up as a near jump or a short jump.
> >
> > > Craig said there is a trick with object file, but I dont know how
to
> do that. Also, why compiling to object file changes the result?
> >
> > Here's an object file (although I don't know why it's
producing ELF
> rather than Mach-o):
>
> Oh this is cool! Which code in MC is responsible for replacing EB with E9
> when dumping to object file like this???
>
> Thanks.
>
> >
> > $ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 
-filetype=obj
> > a.o
> > $ x86_64-pc-elf-objdump -d a.o
> >
> > a.o:     file format elf32-i386
> >
> >
> > Disassembly of section .text:
> >
> > 00000000 <.text>:
> >   0:    e9 fc ff ff ff          jmp    0x1
> >
> > And here's assembly which is then run through the compiler.
> >
> > $ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386
> -show-encoding |tee b.s
> >         .text
> >         jmp     _label                  # encoding: [0xeb,A]
> >                                        #   fixup A - offset: 1, value:
> _label-1, kind: FK_PCRel_1
> > $ clang -c b.s
> > $ otool -tvj b.o
> > b.o:
> > (__TEXT,__text) section
> > 0000000000000000        e900000000              jmp     0x5
> >
> > As you can see, both produced near jumps. (I assume the difference
> between the offsets has to do with a difference in relocations between ELF
> and Mach-o.)
> >
> > --
> > Stephen Checkoway
> >
> >
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160228/1bd3d6a5/attachment.html>