Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 18 Nov 2015 08:14:19 -0800 | Subject | Re: .gnu.hash into text PHDR? |
| |
On Nov 17, 2015 6:12 AM, "Jiri Slaby" <jslaby@suse.cz> wrote: > > Hi, > > after > commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12 > Author: Andy Lutomirski <luto@amacapital.net> > Date: Thu Aug 6 14:45:45 2015 -0700 > > x86/vdso: Emit a GNU hash > > I believe .gnu.hash in arch/x86/entry/vdso/vdso-layout.lds.S should have > ":text", right?
ld --verbose says:
SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS; .interp : { *(.interp) } .note.gnu.build-id : { *(.note.gnu.build-id) } .hash : { *(.hash) } .gnu.hash : { *(.gnu.hash) }
so I'm not sure it's needed.
Did you confirm that reverting that patch fixes it?
> > Not that it would matter (it is put there automagically), but I noted it > while hunting a new failure inside KVM (host is 4.2 for some time, guest > was upgraded to 4.3 recently). KVM dies when javac invokes gtod: > KVM internal error. Suberror: 1 > emulation failure > ... > [javac] # C [linux-vdso.so.1+0xe45] __vdso_gettimeofday+0x125 > > which is "movl hpet_page+240(%rip), %eax". Any ideas?
That's really weird. Can you send the guest kernel log (or at least anything containing the substrings tsc, hpet, or clock)? Could you also send arch/x86/entry/vdso/vdso64.so{,.dbg} from a bad kernel?
If it's easy in your environment, the /sys/devices/system/clocksource/clocksource0/current_clocksource on the guest as well as the output of dump-vdso_64 from git clone git://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git are also potentially useful.
How did that backtrace show up after the emulation failure? Usually everything's dead when emulation fails for me. Also, the fact that "Code" is blank is suspicious.
My best guess is that the guest doesn't have an hpet (or that the host is providing a totally nonfunctional hpet) and that something (my patch?) is causing an entry into the wrong place in the vdso. Bad relocation, perhaps?
For me, at least, the image seems fine:
$ readelf -s -D vdso64.so
Symbol table for image: Num Buc: Value Size Type Bind Vis Ndx Name 5 0: 0000000000000e70 21 FUNC GLOBAL DEFAULT 12 __vdso_time 10 0: 0000000000000e90 41 FUNC WEAK DEFAULT 12 getcpu 9 0: 0000000000000e90 41 FUNC GLOBAL DEFAULT 12 __vdso_getcpu 3 0: 0000000000000d00 354 FUNC GLOBAL DEFAULT 12 __vdso_gettimeofday 8 0: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6 4 1: 0000000000000d00 354 FUNC WEAK DEFAULT 12 gettimeofday 7 2: 0000000000000a80 630 FUNC GLOBAL DEFAULT 12 __vdso_clock_gettime 6 2: 0000000000000e70 21 FUNC WEAK DEFAULT 12 time 2 2: 0000000000000a80 630 FUNC WEAK DEFAULT 12 clock_gettime
Symbol table of `.gnu.hash' for image: Num Buc: Value Size Type Bind Vis Ndx Name 2 0: 0000000000000a80 630 FUNC WEAK DEFAULT 12 clock_gettime 3 0: 0000000000000d00 354 FUNC GLOBAL DEFAULT 12 __vdso_gettimeofday 4 0: 0000000000000d00 354 FUNC WEAK DEFAULT 12 gettimeofday 5 0: 0000000000000e70 21 FUNC GLOBAL DEFAULT 12 __vdso_time 6 1: 0000000000000e70 21 FUNC WEAK DEFAULT 12 time 7 1: 0000000000000a80 630 FUNC GLOBAL DEFAULT 12 __vdso_clock_gettime 8 2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6 9 2: 0000000000000e90 41 FUNC GLOBAL DEFAULT 12 __vdso_getcpu 10 2: 0000000000000e90 41 FUNC WEAK DEFAULT 12 getcpu
I have the same result if I run readelf -s -D on the output from dump-vdso_64.
--Andy
| |