|
From: Alex B. <ker...@be...> - 2005-11-02 11:07:02
|
Hi, I'm trying to run Valgrind across an x86 app that uses the modify_ldt syscall which seems to get in the way of Valgrind. I has a look though the svn sources and I can see the test case for modify_ldt is commented out and has a note that it is used by Valgrind itself. Running outside Valgrind gives: $: ./mytestprog ldt_entry.entry_number = 125 ldt_entry.base_addr = 3821ec00 ldt_entry.limit = 9944 ldt_entry.seg_32bit = 1 ldt_entry.contents = 0 ldt_entry.read_exec_only = 0 ldt_entry.limit_in_pages = 0 ldt_entry.seg_not_present= 0 ldt_entry.useable = 1 modify_ldt = 0 setFS(1007) libc_nbtest: starting <snip> Whereas under Valgrind: $ /usr/local/bin/valgrind --tool=memcheck ./mytestprog ==9588== Memcheck, a memory error detector. ==9588== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==9588== Using LibVEX rev 1426, a library for dynamic binary translation. ==9588== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==9588== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==9588== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==9588== For more details, rerun with: -v ==9588== ldt_entry.entry_number = 125 ldt_entry.base_addr = 427ae40 ldt_entry.limit = 9944 ldt_entry.seg_32bit = 1 ldt_entry.contents = 0 ldt_entry.read_exec_only = 0 ldt_entry.limit_in_pages = 0 ldt_entry.seg_not_present= 0 ldt_entry.useable = 1 modify_ldt = -1 FATAL ERROR: User segment selector installation failed. Are user selectors enabled? I'm assuming the move in base_addr is because memory has been moved about a bit. I've tried with both the formal 3.0.1 and the SVN sources. Is my attempt to Valgrind this app doomed because of use of the modify_ldt? -- Alex, homepage: http://www.bennee.com/~alex/ You might have mail |
|
From: Tom H. <to...@co...> - 2005-11-02 11:20:17
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> I'm trying to run Valgrind across an x86 app that uses the modify_ldt
> syscall which seems to get in the way of Valgrind. I has a look though
> the svn sources and I can see the test case for modify_ldt is commented
> out and has a note that it is used by Valgrind itself. Running outside
> Valgrind gives:
It's not that it is used by valgrind, it is virtualised by valgrind
because it needs to alter the LDT for the virtual CPU that your code
is running on.
> ldt_entry.entry_number = 125
> ldt_entry.base_addr = 427ae40
> ldt_entry.limit = 9944
> ldt_entry.seg_32bit = 1
> ldt_entry.contents = 0
> ldt_entry.read_exec_only = 0
> ldt_entry.limit_in_pages = 0
> ldt_entry.seg_not_present= 0
> ldt_entry.useable = 1
> modify_ldt = -1
> FATAL ERROR: User segment selector installation failed.
> Are user selectors enabled?
>
> I'm assuming the move in base_addr is because memory has been moved
> about a bit. I've tried with both the formal 3.0.1 and the SVN sources.
> Is my attempt to Valgrind this app doomed because of use of the
> modify_ldt?
The problem is that valgrind 3 currently only emulates the
first 64 entries of the LDT because that is all that the thread
local storage stuff in glibc normally uses.
In fact valgrind 2.4 emulates the entire LDT so your code should
work there.
Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to
a larger number (8192 to get the full LDT) should allow your code
to work I think.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 12:20:16
|
On Wed, 2005-11-02 at 11:20 +0000, Tom Hughes wrote: > In message <113...@ok...> > Alex Bennee <ker...@be...> wrote: > > > I'm trying to run Valgrind across an x86 app that uses the modify_ldt > > syscall which seems to get in the way of Valgrind. > > <snip> > > It's not that it is used by valgrind, it is virtualised by valgrind > because it needs to alter the LDT for the virtual CPU that your code > is running on. > > <snip> > > Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to > a larger number (8192 to get the full LDT) should allow your code > to work I think. Thanks. That worked and it moved forward. Unfortunately we set up the fs segment selector to point at the entry. This doesn't seem to be correctly setup under valgrind: setFS(0x3ef) checkFs(0x427ae40) ==14078== ==14078== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14078== General Protection Fault ==14078== at 0x3808BA9D: peekFs(int) (SegmentSelector.cc:88) <snip> ==14078== starting debugger with cmd: /usr/bin/gdb <snip> 0x3808ba9d in peekFs (offset=0) at SegmentSelector.cc:88 88 __asm__ volatile( (gdb) p $fs $1 = -1342177280 (gdb) p/x $2 = 0xb0000000 Vs running direct under gdb: <snip> Breakpoint 1, peekFs (offset=0) at SegmentSelector.cc:88 88 __asm__ volatile( (gdb) p $fs $1 = 1007 > > Tom -- Alex, homepage: http://www.bennee.com/~alex/ BE ALERT!!!! (The world needs more lerts ...) |
|
From: Tom H. <to...@co...> - 2005-11-02 12:36:29
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> On Wed, 2005-11-02 at 11:20 +0000, Tom Hughes wrote:
>> In message <113...@ok...>
>> Alex Bennee <ker...@be...> wrote:
>>
>> > I'm trying to run Valgrind across an x86 app that uses the modify_ldt
>> > syscall which seems to get in the way of Valgrind.
>> > <snip>
>>
>> It's not that it is used by valgrind, it is virtualised by valgrind
>> because it needs to alter the LDT for the virtual CPU that your code
>> is running on.
>>
>> <snip>
>>
>> Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to
>> a larger number (8192 to get the full LDT) should allow your code
>> to work I think.
>
> Thanks. That worked and it moved forward. Unfortunately we set up the fs
> segment selector to point at the entry. This doesn't seem to be
> correctly setup under valgrind:
>
> setFS(0x3ef)
What instruction(s) is this routine using to set %fs?
It should work - although I think the x86 glibc uses %gs so that
is probably more thoroughly tested.
You could try setting verboze to True in x86g_use_seg_selector
in VEX/priv/guest-x86/ghelpers.c and see what it says - that should
report the segment translations that it does.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-02 13:18:37
|
> > Thanks. That worked and it moved forward. Unfortunately we set up the fs > > segment selector to point at the entry. This doesn't seem to be > > correctly setup under valgrind: > > > > setFS(0x3ef) > > What instruction(s) is this routine using to set %fs? > > It should work - although I think the x86 glibc uses %gs so that > is probably more thoroughly tested. I agree, it should work. Moves to/from segment registers are supported, as are the use of %ds, %es, %fs and %gs in segment override prefixes. J |
|
From: Tom H. <to...@co...> - 2005-11-02 12:40:11
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <113...@ok...>
> Alex Bennee <ker...@be...> wrote:
>
>> Thanks. That worked and it moved forward. Unfortunately we set up the fs
>> segment selector to point at the entry. This doesn't seem to be
>> correctly setup under valgrind:
>>
>> setFS(0x3ef)
>
> What instruction(s) is this routine using to set %fs?
>
> It should work - although I think the x86 glibc uses %gs so that
> is probably more thoroughly tested.
>
> You could try setting verboze to True in x86g_use_seg_selector
> in VEX/priv/guest-x86/ghelpers.c and see what it says - that should
> report the segment translations that it does.
One other thing that just occurred to me - make sure you have
done a make in the VEX directory as doing a make at the top level
doesn't always manage to rebuild VEX correctly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 15:15:05
|
On Wed, 2005-11-02 at 12:40 +0000, Tom Hughes wrote: > In message <yek...@de...> > Tom Hughes <to...@co...> wrote: > > > > > You could try setting verboze to True in x86g_use_seg_selector > > in VEX/priv/guest-x86/ghelpers.c and see what it says - that should > > report the segment translations that it does. I did that and it got further. I suspect it was because I did: > One other thing that just occurred to me - make sure you have > done a make in the VEX directory as doing a make at the top level > doesn't always manage to rebuild VEX correctly. I've been installing this on my system using checkinstall for the "make install" stage and I have noticed that seems to cause a bunch of stuff to get compiled. I guess there must be a subtle bug in the Makefile's somewhere that cause incorrect builds occasionally. Still all good now. The program gets a lot further in before valgrind detects the application loading a non-x86 ELF (which obviously confuses ld.so.1). Still its pointed to enough to be going on with. Thanks for you help today. -- Alex, homepage: http://www.bennee.com/~alex/ Darth Vader sleeps with a Teddywookie. |
|
From: Tom H. <to...@co...> - 2005-11-02 15:37:06
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> Still all good now. The program gets a lot further in before valgrind
> detects the application loading a non-x86 ELF (which obviously confuses
> ld.so.1). Still its pointed to enough to be going on with.
So the question now is whether we should increase the LDT size
limit in VEX which is one for Julian I guess.
Was there any particular reason for the 64 entry limit Julian?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-02 15:42:16
|
> So the question now is whether we should increase the LDT size > limit in VEX which is one for Julian I guess. > > Was there any particular reason for the 64 entry limit Julian? Euh .. can't really remember. I _think_ it might be that each thread has to have its own LDT (is that right?) and so allocating a whole one was a bit wasteful. I'll change it to full-size. J |
|
From: Tom H. <to...@co...> - 2005-11-02 15:49:14
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> So the question now is whether we should increase the LDT size
>> limit in VEX which is one for Julian I guess.
>>
>> Was there any particular reason for the 64 entry limit Julian?
>
> Euh .. can't really remember. I _think_ it might be that each thread
> has to have its own LDT (is that right?) and so allocating a whole one
> was a bit wasteful.
It does, yes. The kernel (and valgrind 2.4) uses a lazy copying scheme
so that the LDT is shared until a thread actually changed it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|