[Qemu-devel] Sparc-linux-user problem

[Qemu-devel] Sparc-linux-user problem

[Blue Swirl]

Hi,

I'm investigating why Sparc32 user emulator breaks when linked with
-lrt. It seems that other libraries also cause the problem, for
example -lm -ldl -lX11 -lbfd -lslang is okay, but  -lm -ldl -lX11
-lbfd -lslang -lglib-2.0 segfaults just like -lm -lrt. If just address
space conflict was the issue, I'd think 12 megs libbfd would trigger
the problem instead of 64k librt.

Any ideas?

Good output (DEBUG_SIGNAL enabled):
qemu-sparc ./ld-linux.so.2
qemu: SIGSEGV pc=0x810d80b4 address=4103fd10 w=1 oldset=0x80000000
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
[cut]

Bad output:
qemu: SIGSEGV pc=0x810d80d4 address=4103fd10 w=1 oldset=0x80000000
qemu: SIGSEGV pc=0x00018000 address=00018000 w=0 oldset=0xfffbfaff
queue_signal: sig=11
qemu: uncaught target signal 11 (Segmentation fault) - exiting

This ld-linux.so.2 is from qemu-tests-0.5.3. The value pc
(=0x810d80d4) changes a bit when libraries are added.

Re: [Qemu-devel] Sparc-linux-user problem

[Paul Brook]

On Saturday 28 April 2007, Blue Swirl wrote:
> Hi,
>
> I'm investigating why Sparc32 user emulator breaks when linked with
> -lrt. It seems that other libraries also cause the problem, for
> example -lm -ldl -lX11 -lbfd -lslang is okay, but  -lm -ldl -lX11
> -lbfd -lslang -lglib-2.0 segfaults just like -lm -lrt. If just address
> space conflict was the issue, I'd think 12 megs libbfd would trigger
> the problem instead of 64k librt.
>
> Any ideas?

I've never got this to work reliably on either x86 or amd64 hosts. I get 
mysterious segfaults in the depths of libc. My guess is that the tricks qemu 
uses to link itself as a shared library are confusing things (possibly the 
TLS initialisation).

Configuring with --enable-static usually works around the problem.

Paul

Re: [Qemu-devel] Sparc-linux-user problem

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sat, 28 Apr 2007 18:20:55 +0100
Paul Brook <paul@codesourcery.com> wrote:

> On Saturday 28 April 2007, Blue Swirl wrote:
> > Hi,
> >
> > I'm investigating why Sparc32 user emulator breaks when linked with
> > -lrt. It seems that other libraries also cause the problem, for
> > example -lm -ldl -lX11 -lbfd -lslang is okay, but  -lm -ldl -lX11
> > -lbfd -lslang -lglib-2.0 segfaults just like -lm -lrt. If just
> > address space conflict was the issue, I'd think 12 megs libbfd
> > would trigger the problem instead of 64k librt.
> >
> > Any ideas?
> 
> I've never got this to work reliably on either x86 or amd64 hosts. I
> get mysterious segfaults in the depths of libc. My guess is that the
> tricks qemu uses to link itself as a shared library are confusing
> things (possibly the TLS initialisation).

I don't suppose using gcc/binutils -fPIE/-pie would achieve qemu's
goals, thus avoiding the need to specify bespoke ld scripts?

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Sparc-linux-user problem

[Paul Brook]

On Saturday 28 April 2007, Kevin F. Quinn wrote:
> On Sat, 28 Apr 2007 18:20:55 +0100
>
> Paul Brook <paul@codesourcery.com> wrote:
> > On Saturday 28 April 2007, Blue Swirl wrote:
> > > Hi,
> > >
> > > I'm investigating why Sparc32 user emulator breaks when linked with
> > > -lrt. It seems that other libraries also cause the problem, for
> > > example -lm -ldl -lX11 -lbfd -lslang is okay, but  -lm -ldl -lX11
> > > -lbfd -lslang -lglib-2.0 segfaults just like -lm -lrt. If just
> > > address space conflict was the issue, I'd think 12 megs libbfd
> > > would trigger the problem instead of 64k librt.
> > >
> > > Any ideas?
> >
> > I've never got this to work reliably on either x86 or amd64 hosts. I
> > get mysterious segfaults in the depths of libc. My guess is that the
> > tricks qemu uses to link itself as a shared library are confusing
> > things (possibly the TLS initialisation).
>
> I don't suppose using gcc/binutils -fPIE/-pie would achieve qemu's
> goals, thus avoiding the need to specify bespoke ld scripts?

Sort-of, maybe.

Paul