[Qemu-devel] Could configure generate QEMU's linker scripts?

[Qemu-devel] Could configure generate QEMU's linker scripts?

[Ed Maste]

On 19 May 2013 10:51, in a thread relating to the sparc-linux-user
linker script, Michael Tokarev <mjt@tls.msk.ru> wrote:
> If we apply this for 1.5, it will be the first release of debian
> package without extra fixes.  Hopefully anyway :)
>
> (Ofcourse we may add more fixes later but... ;)

Would it be reasonable to have QEMU's configure use sed or awk to
start with ld's built-in linker script and transform it with the
necessary modifications?

Improved bsd-user support is in development in FreeBSD, and I'm trying
to upstream the basic changes that are in the FreeBSD ports tree
before others start submitting that work.  One of these changes is a
patch that replaces the x86_64.ld and i386.ld linker scripts with ones
suitable for FreeBSD, but makes them unsuitable for Linux.  I'd rather
not end up just introducing a parallel set of ldscript files for
FreeBSD, so would like to generate it from the default built-in one if
possible.

For the FreeBSD x86-64 case I can create a suitable linker script (at
least, one identical to what's in the FreeBSD ports tree) with just
the following:

ld --verbose | sed \
    -e '1,/==================================================/d' \
    -e '/==================================================/,$d' \
    -e 's/0x400000/0x60000000/g'

That is, it just changes the start address.  Is this generally the
only difference between QEMU's linker scripts and system built-ins?
(Perhaps we're missing other changes in FreeBSD, or platforms other
than x86_64 have more extensive changes?)

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Paolo Bonzini]

Il 19/05/2013 18:30, Ed Maste ha scritto:
> I'd rather
> not end up just introducing a parallel set of ldscript files for
> FreeBSD, so would like to generate it from the default built-in one if
> possible.
> 
> For the FreeBSD x86-64 case I can create a suitable linker script (at
> least, one identical to what's in the FreeBSD ports tree) with just
> the following:
> 
> ld --verbose | sed \
>     -e '1,/==================================================/d' \
>     -e '/==================================================/,$d' \
>     -e 's/0x400000/0x60000000/g'
> 
> That is, it just changes the start address.  Is this generally the
> only difference between QEMU's linker scripts and system built-ins?
> (Perhaps we're missing other changes in FreeBSD, or platforms other
> than x86_64 have more extensive changes?)

Is this still needed if you compile QEMU with PIE?  Currently we do that
only for a few architectures due to lack of testing, but it could well
be made the default, and help dropping the linker scripts.

Paolo

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Aurelien Jarno]

On Sun, May 19, 2013 at 09:24:41PM +0200, Paolo Bonzini wrote:
> Il 19/05/2013 18:30, Ed Maste ha scritto:
> > I'd rather
> > not end up just introducing a parallel set of ldscript files for
> > FreeBSD, so would like to generate it from the default built-in one if
> > possible.
> > 
> > For the FreeBSD x86-64 case I can create a suitable linker script (at
> > least, one identical to what's in the FreeBSD ports tree) with just
> > the following:
> > 
> > ld --verbose | sed \
> >     -e '1,/==================================================/d' \
> >     -e '/==================================================/,$d' \
> >     -e 's/0x400000/0x60000000/g'
> > 
> > That is, it just changes the start address.  Is this generally the
> > only difference between QEMU's linker scripts and system built-ins?
> > (Perhaps we're missing other changes in FreeBSD, or platforms other
> > than x86_64 have more extensive changes?)
> 
> Is this still needed if you compile QEMU with PIE?  Currently we do that
> only for a few architectures due to lack of testing, but it could well
> be made the default, and help dropping the linker scripts.
> 

You can't compile with PIE and static, and actually the patch which
triggered this new thread is only need when building a static binary.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Richard Henderson]

On 05/19/2013 09:30 AM, Ed Maste wrote:
> On 19 May 2013 10:51, in a thread relating to the sparc-linux-user
> linker script, Michael Tokarev <mjt@tls.msk.ru> wrote:
>> If we apply this for 1.5, it will be the first release of debian
>> package without extra fixes.  Hopefully anyway :)
>>
>> (Ofcourse we may add more fixes later but... ;)
> 
> Would it be reasonable to have QEMU's configure use sed or awk to
> start with ld's built-in linker script and transform it with the
> necessary modifications?

In general I believe that using the -Ttext-segment ADDR flag for ld
would completely obviate the need for even editing the link script.

> That is, it just changes the start address.  Is this generally the
> only difference between QEMU's linker scripts and system built-ins?

Yes.


r~

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Ed Maste]

On 20 May 2013 13:21, Richard Henderson <rth@twiddle.net> wrote:
> In general I believe that using the -Ttext-segment ADDR flag for ld
> would completely obviate the need for even editing the link script.

That sounds cleaner, although there's a wrinkle for FreeBSD.  We're
still using binutils version 2.17.50 in the base system, since it is
the last one licensed under GPLv2, and it doesn't support the
-Ttext-segment flag.  There is -Ttext but it still leaves some parts
behind at the default load address.  I assume that the reason for
changing the QEMU load address is to leave the default free for the
guest application to use, making -Ttext unsuitable.

If we can't use an approach along the lines of my earlier sed script
we'll just have to find a way to support -Ttext-segment in FreeBSD,
either by having the original patch that introduced it made available
under GPLv2, reimplementing the functionality, or by requiring use of
a later binutils (from the FreeBSD ports tree).

One oddity I noticed is that alpha and s390x seem to not use the ld
script (with the comment "The default placement of the application is
fine" in configure), so I'm not sure why QEMU includes those files.
It also looks like mips.ld may have no changes from the default (it
leaves the load address at 0x0400000).

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Richard Henderson]

On 05/21/2013 10:51 AM, Ed Maste wrote:
> On 20 May 2013 13:21, Richard Henderson <rth@twiddle.net> wrote:
>> In general I believe that using the -Ttext-segment ADDR flag for ld
>> would completely obviate the need for even editing the link script.
> 
> That sounds cleaner, although there's a wrinkle for FreeBSD.  We're
> still using binutils version 2.17.50 in the base system, since it is
> the last one licensed under GPLv2, and it doesn't support the
> -Ttext-segment flag.  There is -Ttext but it still leaves some parts
> behind at the default load address.  I assume that the reason for
> changing the QEMU load address is to leave the default free for the
> guest application to use, making -Ttext unsuitable.
> 
> If we can't use an approach along the lines of my earlier sed script
> we'll just have to find a way to support -Ttext-segment in FreeBSD,
> either by having the original patch that introduced it made available
> under GPLv2, reimplementing the functionality, or by requiring use of
> a later binutils (from the FreeBSD ports tree).

Certainly using a decent binutils would be easiest.

Although for the purposes of getting the qemu application out of the virtual
address space that the *-bsd-user guest will want to use, it might be better to
use -fPIE.  At least on linux that tends to put the x86_64 host binary up in
(very) high memory.

The best long term solution is to be able to enable softmmu for *-user guests.
 It's the only way to make certain 64-on-32 combinations work, and the only way
to fix a myriad of problems that occur when the host and guest page sizes don't
match.  At which point it doesn't matter where the host binary resides.

> One oddity I noticed is that alpha and s390x seem to not use the ld
> script (with the comment "The default placement of the application is
> fine" in configure), so I'm not sure why QEMU includes those files.

I thought I deleted those when I changed the configure script...


r~

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Peter Maydell]

On 20 May 2013 18:21, Richard Henderson <rth@twiddle.net> wrote:
> On 05/19/2013 09:30 AM, Ed Maste wrote:
>> That is, it just changes the start address.  Is this generally the
>> only difference between QEMU's linker scripts and system built-ins?
>
> Yes.

So for a new architecture how do we determine whether we need
to fiddle with the start address or not? (More specifically,
is aarch64 going to need a linker script or just to go in the
configure list of "hosts which don't need one" ?)

thanks
-- PMM

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Richard Henderson]

On 06/02/2013 10:15 AM, Peter Maydell wrote:
> So for a new architecture how do we determine whether we need
> to fiddle with the start address or not? (More specifically,
> is aarch64 going to need a linker script or just to go in the
> configure list of "hosts which don't need one" ?)

Basically, for a non-PIE build, is there room to run the -linux-user guest
binary?  That means getting out of the way of the guest's default link
location.  If the host default link location is above 2G you may be good; above
4G is even better.


r~

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Peter Maydell]

On 3 June 2013 15:23, Richard Henderson <rth@twiddle.net> wrote:
> On 06/02/2013 10:15 AM, Peter Maydell wrote:
>> So for a new architecture how do we determine whether we need
>> to fiddle with the start address or not? (More specifically,
>> is aarch64 going to need a linker script or just to go in the
>> configure list of "hosts which don't need one" ?)
>
> Basically, for a non-PIE build, is there room to run the
> -linux-user guest binary?  That means getting out of the
> way of the guest's default link location.  If the host
> default link location is above 2G you may be good; above
> 4G is even better.

Well, the output of ld --verbose says:

  PROVIDE (__executable_start = SEGMENT_START("text-segment",
0x400000)); . = SEGMENT_START("text-segment", 0x400000) +
SIZEOF_HEADERS;

and objdump of a random aarch64 binary suggests the
text segment defaults to a vaddr of 0x400000, so I guess
that means we need to change the start address.

thanks
-- PMM

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Richard Henderson]

On 06/03/2013 07:57 AM, Peter Maydell wrote:
> Well, the output of ld --verbose says:
> 
>   PROVIDE (__executable_start = SEGMENT_START("text-segment",
> 0x400000)); . = SEGMENT_START("text-segment", 0x400000) +
> SIZEOF_HEADERS;
> 
> and objdump of a random aarch64 binary suggests the
> text segment defaults to a vaddr of 0x400000, so I guess
> that means we need to change the start address.

Yep.


r~

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Claudio Fontana]

On 03.06.2013 16:57, Peter Maydell wrote:
> On 3 June 2013 15:23, Richard Henderson <rth@twiddle.net> wrote:
>> On 06/02/2013 10:15 AM, Peter Maydell wrote:
>>> So for a new architecture how do we determine whether we need
>>> to fiddle with the start address or not? (More specifically,
>>> is aarch64 going to need a linker script or just to go in the
>>> configure list of "hosts which don't need one" ?)
>>
>> Basically, for a non-PIE build, is there room to run the
>> -linux-user guest binary?  That means getting out of the
>> way of the guest's default link location.  If the host
>> default link location is above 2G you may be good; above
>> 4G is even better.
> 
> Well, the output of ld --verbose says:
> 
>   PROVIDE (__executable_start = SEGMENT_START("text-segment",
> 0x400000)); . = SEGMENT_START("text-segment", 0x400000) +
> SIZEOF_HEADERS;
> 
> and objdump of a random aarch64 binary suggests the
> text segment defaults to a vaddr of 0x400000, so I guess
> that means we need to change the start address.
> 
> thanks
> -- PMM
> 

I'm trying to get this to run, in order to be able to test the aarch64 TCG User mode support I have under development.

I wrote an aarch64.ld script based on the sections of other binaries, using a high address (0x0600000000). Before I tried what seemed to be the standard number for non-x86(0x0060000000), with the same results.

The program actually runs (I can qemu-x86-64 --help, for example),
but I get in trouble with the bss, in the sense that I get a sigfault at runtime as soon as the QEMU code tries to initialize the TCG Context (tcg_ctx, residing in bss) with memset, during tcg_context_init():

qemu-x86_64[418]: unhandled level 3 translation fault (11) at 0x602187000, esr 0x92000047
pgd = ffffffc01aef8000
[602187000] *pgd=000000009ae52003, *pmd=000000009aef9003, *pte=0000000000000000

Pid: 418, comm:          qemu-x86_64
CPU: 0    Not tainted  (3.8.0-rc6+ #3)
PC is at 0x7fb7d0b2f0
LR is at 0x6000c0494
pc : [<0000007fb7d0b2f0>] lr : [<00000006000c0494>] pstate: 20000000
sp : 0000007ffffff480
x29: 0000007ffffff480 x28: 0000000000000000 
x27: 0000000000000000 x26: 0000000000000000 
x25: 0000000000000000 x24: 0000000000000000 
x23: 0000000000000000 x22: 0000000000000000 
x21: 00000006000073e8 x20: 0000000000000000 
x19: 0000000000000000 x18: 0000007fffffe250 
x17: 0000007fb7d0b2a8 x16: 000000060011fd70 
x15: 0016fcc9b4000000 x14: 0000000000000008 
x13: 00000003e8000000 x12: 0000000000000000 
x11: 0000000000000000 x10: 0000007fb7c92ba8 
x9 : 0000000600006424 x8 : 0000000000000038 
x7 : 0000000000001569 x6 : 000000000000002b 
x5 : 0000000000000000 x4 : 0000000602132080 
x3 : 0000000602187000 x2 : 0000000000055a60 
x1 : 0000000000000000 x0 : 0000000602132080 

Program received signal SIGSEGV, Segmentation fault.
__GI_memset (dstpp=0x602132080 <tcg_ctx>, c=0, len=350816) at memset.c:56
56                ((op_t *) dstp)[0] = cccc;
(gdb) bt
#0  __GI_memset (dstpp=0x602132080 <tcg_ctx>, c=0, len=350816) at memset.c:56
#1  0x00000006000c0494 in tcg_context_init (s=0x602132080 <tcg_ctx>)
    at /home/claudio/git/qemu-really-new/tcg/tcg.c:236
#2  0x00000006000c6988 in cpu_gen_init ()
    at /home/claudio/git/qemu-really-new/translate-all.c:130
#3  0x00000006000c7194 in tcg_exec_init (tb_size=0)
    at /home/claudio/git/qemu-really-new/translate-all.c:592
#4  0x000000060004b9cc in main (argc=2, argv=0x7ffffffdb8, envp=0x7ffffffdd0)
    at /home/claudio/git/qemu-really-new/linux-user/main.c:3624

----

This is the aarch64.ld script I am using. The problem is probably here,
since I wrote it without fully understanding it.
Can someone save the day?

----

OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64");
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0x600000000 + SIZEOF_HEADERS;
  .interp         : { *(.interp) }
  .hash           : { *(.hash) }
  .dynsym         : { *(.dynsym) }
  .dynstr         : { *(.dynstr)	}
  .gnu.version    : { *(.gnu.version) }
  .gnu.version_r  : { *(.gnu.version_r) }
  .gnu.version_d  : { *(.gnu.version_d) }

  .rel.dyn        : {
    *(.rel.dyn)
    *(.rel.init)
    *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
    *(.rel.fini)
    *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
    *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
    *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
    *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
    *(.rel.ctors)
    *(.rel.dtors)
    *(.rel.got)
    *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
  }

  .rel.plt        : {
    *(.rel.plt)
    PROVIDE (__rel_iplt_start = .);
    *(.rel.iplt)
    PROVIDE (__rel_iplt_end = .);
  }

  .rela.dyn       : {
    *(.rela.dyn)
    *(.rela.init)
    *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
    *(.rela.fini)
    *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
    *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
    *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
    *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
    *(.rela.ctors)
    *(.rela.dtors)
    *(.rela.got)
    *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
  }

  .rela.plt       : {
    *(.rela.plt)
    PROVIDE (__rela_iplt_start = .);
    *(.rela.iplt)
    PROVIDE (__rela_iplt_end = .);
  }

  .init           : { *(.init) } = 0x600000000
  .plt            : { *(.plt) }
  .text           : {
    *(.text)
    *(.gnu.warning)
    *(.gnu.linkonce.t*)
  } = 0x600000000
  _etext = .;
  PROVIDE (etext = .);

  .fini           : { *(.fini)    } = 0x600000000
  .rodata         : { *(.rodata) *(.gnu.linkonce.r*) }

   __exidx_start = .;
  .ARM.exidx      : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
   __exidx_end = .;
  .ARM.extab      : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
  .ARM.attributes : { *(.ARM.attributes* .gnu.linkonce.armattributes.*) }

  .eh_frame       : { KEEP (*(.eh_frame)) }

  . = ALIGN(64 / 8);

  .preinit_array :
  {
    PROVIDE (__preinit_array_start = .);
    KEEP (*(.preinit_array))
    PROVIDE (__preinit_array_end = .);
  }
  .init_array    :
  {
     PROVIDE (__init_array_start = .);
     KEEP (*(SORT(.init_array.*)))
     KEEP (*(.init_array))
     PROVIDE (__init_array_end = .);
  }
  .fini_array    :
  {
    PROVIDE (__fini_array_start = .);
    KEEP (*(.fini_array))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE (__fini_array_end = .);
  }

  .jcr           : { KEEP (*(.jcr)) }
  .dynamic       : { *(.dynamic) }
  .got           : { *(.got) }
  .got.plt       : { *(.got.plt) }
  .data          : {
    *(.gen_code .data .data.* .gnu.linkonce.d*)
    SORT(CONSTRUCTORS)
  }

  . = ALIGN(64 / 8);
  __bss_start = .;
  .bss           : {
    *(.dynbss)
    *(.bss .bss.* .gnu.linkonce.b.*)
    *(COMMON)
    /* Align here to ensure that the .bss section occupies space up to
       _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections. */
    . = ALIGN(64 / 8);
  }
  _end = .;
  PROVIDE (end = .);

  /* Stabs debugging sections.  */
  .stab 0          : { *(.stab) }
  .stabstr 0       : { *(.stabstr) }
  .stab.excl 0     : { *(.stab.excl) }
  .stab.exclstr 0  : { *(.stab.exclstr) }
  .stab.index 0    : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0       : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug 0           : { *(.debug) }
  .line 0            : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo 0   : { *(.debug_srcinfo) }
  .debug_sfnames 0   : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges 0   : { *(.debug_aranges) }
  .debug_pubnames 0  : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info 0      : { *(.debug_info) }
  .debug_abbrev 0    : { *(.debug_abbrev) }
  .debug_line 0      : { *(.debug_line) }
  .debug_frame 0     : { *(.debug_frame) }
  .debug_str 0       : { *(.debug_str) }
  .debug_loc 0       : { *(.debug_loc) }
  .debug_macinfo 0   : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  .debug_ranges 0    : { *(.debug_ranges) }

  .note.gnu.build-id : { *(.note.gnu.build-id) }

  /* These must appear regardless of  .  */
  /DISCARD/ : { *(.note.GNU-stack) *(.note.ABI-tag) }
}

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Peter Maydell]

On 4 June 2013 16:55, Claudio Fontana <claudio.fontana@huawei.com> wrote:
> I'm trying to get this to run, in order to be able to test the
> aarch64 TCG User mode support I have under development.

Does it work as a first pass with aarch64 put in the
configure list of "doesn't need a linker script"?
Since we now default to "reserve 4GB space and
set guest-base" this should work OK (if all the
TCG bits are right). Fiddling with the start
address is only needed for the "-R 0" no-reserved-mem
case.

I think this should let you debug the two issues
separately...

thanks
-- PMM

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Richard Henderson]

On 06/04/2013 09:13 AM, Peter Maydell wrote:
> Since we now default to "reserve 4GB space and
> set guest-base" this should work OK (if all the
> TCG bits are right).

Indeed it should.

Which reminds me... we should remove the bits that make guest-base optional,
now that all TCG backends support it.


r~

Re: [Qemu-devel] Could configure generate QEMU's linker scripts?

[Claudio Fontana]

On 04.06.2013 18:13, Peter Maydell wrote:
> On 4 June 2013 16:55, Claudio Fontana <claudio.fontana@huawei.com> wrote:
>> I'm trying to get this to run, in order to be able to test the
>> aarch64 TCG User mode support I have under development.
> 
> Does it work as a first pass with aarch64 put in the
> configure list of "doesn't need a linker script"?

Yes! :)

> Since we now default to "reserve 4GB space and
> set guest-base" this should work OK (if all the
> TCG bits are right). Fiddling with the start
> address is only needed for the "-R 0" no-reserved-mem
> case.
> 
> I think this should let you debug the two issues
> separately...
> 
> thanks
> -- PMM
> 

$ ./qemu-x86_64 ./user_mode_test_binary_x86.out
I am a binary executable, and I actually run!
$

I'll make it nice now, then post a series for TCG User mode.
I am using my quirky workaround for the getdents issue, I will now apply Peter's patch instead and test the whole thing.

Claudio