qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu-user-x86_64 segfaults on armv5 (WAS: qemu-user + netwo


From: Christof Schulze
Subject: [Qemu-devel] qemu-user-x86_64 segfaults on armv5 (WAS: qemu-user + networking issues / segfaults)
Date: Fri, 06 Sep 2013 12:38:21 +0200
User-agent: KMail/4.10.5 (Linux/3.8.0-27-generic; KDE/4.10.5; x86_64; ; )

Hello

Am Mittwoch, 4. September 2013, 08:35:37 schrieb Richard Henderson:
> On 08/29/2013 02:27 PM, Christof Schulze wrote:
> > #5  0x6012a100 in tb_gen_code (env=0x612def20, pc=18446744073699066880,
> > cs_base=0, flags=4243635, cflags=0)

> >     at /mnt/data/build/qemu-1.6.0-ministatic/translate-all.c:964

> In know exactly what this is -- the fallback vsyscall page.

> I've had a patch set around for the last three years or so to provide
> a real vdso for x86_64.  I repost it every so often, usually to no
> response.

> See git://github.com/rth7680/qemu.git elfload-vdso
after trying the patch itself and still getting slightly other crashes
on irc we decided to try this patch based on the master branch. This
allowed for debugging with gdb as it circumvented a bug of the early
1.6rcs of qemu where the g packet was transmitting two many registers.


Having set a breakpoint at *0x0000000040816725 (the memory position
where the segfault happens) I got the following
output.

Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000000040802650 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b *0x0000000040816725
Haltepunkt 1 at 0x40816725: file ../sysdeps/x86_64/dl-trampoline.S, line 46.
(gdb) cont
Continuing.
Breakpoint 1, _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:46
46      ../sysdeps/x86_64/dl-trampoline.S: Datei oder Verzeichnis nicht 
gefunden.
it says dl-trampoline.S: file or directory not found and gives me the
gdb shell

Breakpoint 1, _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:46
46      in ../sysdeps/x86_64/dl-trampoline.S
(gdb) 
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xffffffffff600400 in ?? ()

RTH mentioned that the runtime resolution of the symbol was into the
vsyscall page.

Now I am unsure where I should go from this point.
Should I collect more data? If so, what exactly is needed? 
What else could I do to get this resolved?

Christof

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]