|
From: <js...@ac...> - 2004-03-13 03:48:07
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-13 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 143 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@ca...> - 2004-03-16 17:09:34
|
On Sat, 13 Mar 2004 js...@ac... wrote: > == 143 tests, 13 stderr failures, 0 stdout failures ================= > corecheck/tests/as_mmap (stderr) > corecheck/tests/fdleak_cmsg (stderr) > corecheck/tests/fdleak_creat (stderr) > corecheck/tests/fdleak_dup (stderr) > corecheck/tests/fdleak_dup2 (stderr) > corecheck/tests/fdleak_fcntl (stderr) > corecheck/tests/fdleak_ipv4 (stderr) > corecheck/tests/fdleak_open (stderr) > corecheck/tests/fdleak_pipe (stderr) > corecheck/tests/fdleak_socketpair (stderr) > helgrind/tests/inherit (stderr) > memcheck/tests/writev (stderr) > memcheck/tests/zeropage (stderr) > > make: *** [regtest] Error 1 Tom, Julian, Any chance of adding extra .stderr.exp* files or improving the filters so that the not-really-failing tests pass? With the current failures, these messages are little more than noise... N |
|
From: Tom H. <th...@cy...> - 2004-03-16 18:16:47
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> Any chance of adding extra .stderr.exp* files or improving the filters so
> that the not-really-failing tests pass? With the current failures, these
> messages are little more than noise...
I haven't done that for those ones because I'm still trying to make
the sysinfo page solution that Jeremy suggested work, and that should
remove those.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-03-17 16:21:17
|
On Tue, 2004-03-16 at 10:16, Tom Hughes wrote: > I haven't done that for those ones because I'm still trying to make > the sysinfo page solution that Jeremy suggested work, and that should > remove those. Oh? What are you trying out? BTW, one of our other options is to special case the _dl_sysinfo_80 (whatever it is) function as well. J |
|
From: Tom H. <th...@cy...> - 2004-03-17 16:29:26
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-03-16 at 10:16, Tom Hughes wrote:
>> I haven't done that for those ones because I'm still trying to make
>> the sysinfo page solution that Jeremy suggested work, and that should
>> remove those.
>
> Oh? What are you trying out?
Well I was going to try and create a separate shared object that we
could map into the sysinfo page, that way we could set the EHDR entry
as well which should make glibc use the sysinfo page. I just haven't
had time to try it yet...
> BTW, one of our other options is to special case the _dl_sysinfo_80
> (whatever it is) function as well.
Indeed.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-03-17 23:06:32
|
On Wed, 2004-03-17 at 08:28, Tom Hughes wrote:
> In message <107...@ix...>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
> > On Tue, 2004-03-16 at 10:16, Tom Hughes wrote:
> >> I haven't done that for those ones because I'm still trying to make
> >> the sysinfo page solution that Jeremy suggested work, and that should
> >> remove those.
> >
> > Oh? What are you trying out?
>
> Well I was going to try and create a separate shared object that we
> could map into the sysinfo page, that way we could set the EHDR entry
> as well which should make glibc use the sysinfo page. I just haven't
> had time to try it yet...
I just got a chance to download and look at the glibc 2.3.3/FC2 sources,
which want to see the AT_SYSINFO_EHDR entry. It pretty clearly expects
to see a prelinked, premapped .so file containing the vsyscall
entrypoint. If we want to put this near the top of the client address
space, then we will need to be able to generate one of these with
different linked addresses, depending on where it has been placed. This
seems like too much hard work to me.
The other options I can see are:
1. just use the kernel provided EHDR, but copy it into the client
address space. When we see jumps to the kernel's sysinfo page
at 0xffffd000, use the EIP redirection to point it somewhere
more useful. I don't know what happens if we copy the EHDR to
another address without changing it though, but otherwise this
seems pretty simple.
2. Pick a low address (say, 64k), and put the sysinfo+sysinfo_ehdr
there. It will be fixed regardless of the client address space
configuration. The downside is that some programs may be linked
to go there, so we should place it only if there are no mappings
from the client executable there.
3. Special-case _dl_sysinfo_int80. Not too keen on this, but easy.
I might try hacking one of these up, unless you get to it first.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 09:19:55
|
On Wed, 17 Mar 2004, Jeremy Fitzhardinge wrote: > I just got a chance to download and look at the glibc 2.3.3/FC2 sources, > which want to see the AT_SYSINFO_EHDR entry. It pretty clearly expects > to see a prelinked, premapped .so file containing the vsyscall > entrypoint. If we want to put this near the top of the client address > space, then we will need to be able to generate one of these with > different linked addresses, depending on where it has been placed. This > seems like too much hard work to me. > > The other options I can see are: [snip] I only partly understand this thread, but reading it I'm thinking: this all sounds very complicated for something that only(?) affects FC2... can we avoid doing anything, or do something simple? It makes me uncomfortable every time we have to build in some special handling for a particular version of a library or whatever. Just an observation. N |
|
From: Jeremy F. <je...@go...> - 2004-03-18 18:44:58
Attachments:
sysinfo-ehdr.patch
|
On Thu, 2004-03-18 at 01:19, Nicholas Nethercote wrote: > I only partly understand this thread, but reading it I'm thinking: this > all sounds very complicated for something that only(?) affects FC2... can > we avoid doing anything, or do something simple? It makes me > uncomfortable every time we have to build in some special handling for a > particular version of a library or whatever. Just an observation. No, it isn't library-specific. It's actually a new(ish) kernel interface, which libraries are starting to use. Ultimately it's cosmetic though; it's about showing the right function when we're showing the backtrace of a thread in a syscall. This patch works for me with --pointercheck=no. Unfortunately, just copying the linux-gate.so into the client address space isn't enough. J |
|
From: Tom H. <th...@cy...> - 2004-03-22 19:48:31
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2004-03-18 at 01:19, Nicholas Nethercote wrote:
> > I only partly understand this thread, but reading it I'm thinking: this
> > all sounds very complicated for something that only(?) affects FC2... can
> > we avoid doing anything, or do something simple? It makes me
> > uncomfortable every time we have to build in some special handling for a
> > particular version of a library or whatever. Just an observation.
>
> No, it isn't library-specific. It's actually a new(ish) kernel
> interface, which libraries are starting to use. Ultimately it's
> cosmetic though; it's about showing the right function when we're
> showing the backtrace of a thread in a syscall.
>
> This patch works for me with --pointercheck=no. Unfortunately, just
> copying the linux-gate.so into the client address space isn't enough.
Your patch also doesn't help in my case, because my kernel isn't
actually supplying a sysinfo page and I was trying to get valgrind
to make one up so that the special unwind hack would kick in.
I've come up with a simpler solution for my problem now. I've added
a redirect from _dl_sysinfo_int80 to the system call routine in
valgrind's trampoline page, which valgrind will then recognise and
do it's special unwind trick on.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-03-23 06:56:22
|
Quoting Tom Hughes <th...@cy...>: > I've come up with a simpler solution for my problem now. I've added > a redirect from _dl_sysinfo_int80 to the system call routine in > valgrind's trampoline page, which valgrind will then recognise and > do it's special unwind trick on. Hah - I was just about to send you that patch to try. Since it's a two-liner, it seems like the right solution. J |
|
From: Tom H. <th...@cy...> - 2004-03-18 09:35:42
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> I only partly understand this thread, but reading it I'm thinking: this
> all sounds very complicated for something that only(?) affects FC2... can
> we avoid doing anything, or do something simple? It makes me
> uncomfortable every time we have to build in some special handling for a
> particular version of a library or whatever. Just an observation.
This isn't about FC2 although it will affect it. It is currently
affecting my FC builds and one of Julian's SuSE builds I think. It
will likely affect most future distributions as well.
The visible effect is that any system call errors are reported as
being in _dl_sysinfo_int80 instead of whichever system call was being
called at the time.
Newer kernels and glibcs support a system whereby the kernel provides a
routine which glibc uses to make system calls. That allows the kernel
to replace the use of int80 for system calls with sysenter/syscall or
whatever depending on the CPU you have.
The address of that routine was originally provided by the AT_SYSINFO
entry in the auxv given to the program, and if it wasn't present then
glibc would use it's internal _dl_sysinfo_int80 routine instead which
just does things the old way.
At some point the system was changed so that rather than just
injecting code into the process the kernel actually maps a small
shared object and sets AT_SYSINFO_EHDR to point to the ELF header
for that object. It also sets AT_SYSINFO still for backwards
compatibility. Newer glibcs effectively ignore AT_SYSINFO however
unless AT_SYSINFO_EHDR is also set.
So on FC1 the kernel doesn't provide a sysinfo page anyway, so all the
stack traces appear to be in _dl_sysinfo_int80 which is why Jeremy
suggested always mapping our own sysinfo page even if the kernel
didn't supply one - currently we only replace any kernel supplied value.
That didn't work however as valgrind only provides an old style
sysinfo page rather than an ELF object so glibc ignored it. Hence
the reason that we are trying to work our how to provide a new style
sysinfo page.
As far as I know 2.6 has sysinfo support by default so this will be an
issue going forward - it isn't clear to me if 2.4 ever had it or
whether RedHat et al have been adding it. RH9 seemed to have it but
then it went away again in FC1 which is a bit odd.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 10:31:13
|
On Thu, 18 Mar 2004, Tom Hughes wrote: > > I only partly understand this thread, but reading it I'm thinking: this > > all sounds very complicated for something that only(?) affects FC2... can > > we avoid doing anything, or do something simple? It makes me > > uncomfortable every time we have to build in some special handling for a > > particular version of a library or whatever. Just an observation. > > This isn't about FC2 although it will affect it. It is currently > affecting my FC builds and one of Julian's SuSE builds I think. It > will likely affect most future distributions as well. Right. I didn't really mean to cast doubt on this particular proposal. I more just wanted to gently remind everyone about the dangers of complexity; in general, just because we can do something doesn't mean we necessarily should. N |