|
From: Nicholas N. <nj...@cs...> - 2005-03-11 00:21:39
|
Jeremy, I'm struggling again to get PIE to work, in order to self-host. I'm not sure if I've got GCC set up right for it to work. Looking at a single-file example, if I just compile in a single step, it doesn't work, viz: [~] gcc4 -fpie a.c [~] file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped If I compile and link in separate stages, it does work: [~] gcc4 -fpie -c a.c [~] gcc4 -pie a.o [~] file a.out a.out: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Does this look right? So PIE seems to be working at least a bit, but seemingly not enough to compile valgrind and self-host. Any ideas? N |
|
From: Jeremy F. <je...@go...> - 2005-03-11 04:15:26
|
Nicholas Nethercote wrote:
> Jeremy,
>
> I'm struggling again to get PIE to work, in order to self-host. I'm
> not sure if I've got GCC set up right for it to work.
>
> Looking at a single-file example, if I just compile in a single step,
> it doesn't work, viz:
>
> [~] gcc4 -fpie a.c
> [~] file a.out
> a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped
>
>
> If I compile and link in separate stages, it does work:
>
> [~] gcc4 -fpie -c a.c
> [~] gcc4 -pie a.o
> [~] file a.out
> a.out: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
> not stripped
>
>
> Does this look right? So PIE seems to be working at least a bit, but
> seemingly not enough to compile valgrind and self-host. Any ideas?
I think so. The gcc manpage mentions -pie as a linker option and -fpie
as a codegen option, and that's what coregrind/Makefile does too.
Oh, wait, you mean that the thing which the Valgrind build process
generates is wrong? And its passing -fpie/-pie in the appropriate
places? What does the complete build output look like? I wonder if
there's some interaction with the other link-time flags we're passing
which inhibits -pie.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-11 05:24:44
|
On Thu, 10 Mar 2005, Jeremy Fitzhardinge wrote: > Oh, wait, you mean that the thing which the Valgrind build process generates > is wrong? And its passing -fpie/-pie in the appropriate places? Ah, I've figured it out: I was trying to run a PIE-Valgrind under a non-PIE-Valgrind. But if I run a PIE-Valgrind under itself, it works. I don't understand why, but cool! (I get an assertion failure from the leak checker on exit, but it's a start...) N |
|
From: Jeremy F. <je...@go...> - 2005-03-11 07:07:42
|
Nicholas Nethercote wrote:
> Ah, I've figured it out: I was trying to run a PIE-Valgrind under a
> non-PIE-Valgrind. But if I run a PIE-Valgrind under itself, it works.
> I don't understand why, but cool!
ume.c has a hack which is dependent on HAVE_PIE. It shouldn't be
necessary, but I haven't put any thought into working out the correct fix.
> (I get an assertion failure from the leak checker on exit, but it's a
> start...)
Which assertion? The one about overlapping heap blocks?
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-11 13:52:11
Attachments:
x
|
On Thu, 10 Mar 2005, Jeremy Fitzhardinge wrote: >> (I get an assertion failure from the leak checker on exit, but it's a >> start...) > > Which assertion? The one about overlapping heap blocks? Looks like it. See attached log of double-valgrinding the program 'date'. N |
|
From: Julian S. <js...@ac...> - 2005-03-11 14:10:59
|
Looks like 2.4.0 is shaping up to be a really good release. Cool. Random thought: we should practice what we preach: is it possible (in general, not for 2.4.0, don't want to delay that) to get V to check V when running the entire testsuite? That might shake out a few more memory management nasties. J On Friday 11 March 2005 13:52, Nicholas Nethercote wrote: > On Thu, 10 Mar 2005, Jeremy Fitzhardinge wrote: > >> (I get an assertion failure from the leak checker on exit, but it's a > >> start...) > > > > Which assertion? The one about overlapping heap blocks? > > Looks like it. See attached log of double-valgrinding the program 'date'. > > N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-11 14:23:30
|
On Fri, 11 Mar 2005, Julian Seward wrote: > Random thought: we should practice what we preach: is it possible > (in general, not for 2.4.0, don't want to delay that) to get V to > check V when running the entire testsuite? That might shake out a > few more memory management nasties. It's definitely worth aiming at. I certainly want to get unit testing up and run the unit tests both natively and under V. (vgtest_ume.c was a first attempt at that, although it's unfortunately broken on many machines). As for V-on-V'ing the whole suite, who knows? I wonder how long it would take :) We could add another line to the .vgtest files that specifies if the regtest is suitable for V-on-V'ing. N |
|
From: Robert W. <rj...@du...> - 2005-03-11 18:39:20
|
> As for V-on-V'ing the whole suite, who knows? I wonder how long it would= =20 > take :) We could add another line to the .vgtest files that specifies if= =20 > the regtest is suitable for V-on-V'ing. Default this one to "yes" and have the .vgtest file disable it... --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2005-03-11 22:23:31
|
Nicholas Nethercote wrote: > It's definitely worth aiming at. I certainly want to get unit testing > up and run the unit tests both natively and under V. (vgtest_ume.c > was a first attempt at that, although it's unfortunately broken on > many machines). > > As for V-on-V'ing the whole suite, who knows? I wonder how long it > would take :) We could add another line to the .vgtest files that > specifies if the regtest is suitable for V-on-V'ing. The biggest problem with V-on-V'ing is that if the outer Valgrind replaces malloc (ie, memcheck, addrcheck, etc), then you can only run tools which also do so on the inner Valgrind. So you can run memcheck on massif, but not on nulgrind. I haven't fully worked out why, but I'm sure its related to the fact that the outer Valgrind sees too deeply. That is, if you have the command line "Vouter Vinner Client", then Vouter sees all the syscalls done by both Vinner and Client; if Client loads libc, then both Vinner *and* Vouter start doing intercepts on it (with Vouter also intercepting Vinner's own libc usage). It would be nice to have a mechanism whereby Vouter can be convinced to look for symbol info in Vinner's direct mmaps, and not Vinner's mmaps on behalf of the client, but I'm not sure exactly how that would work. (Fortunately Vouter doesn't see the Client's client requests; that would get really messy.) The leakcheck assertion-on-nested heapblocks is bug 100628 <http://bugs.kde.org/show_bug.cgi?id=100628>. I think we definitely need some way to represent nesting of heap blocks to deal with pools and sub-allocations, but coming up with something which is general, well-defined and simple is tricky. J |
|
From: Tom H. <to...@co...> - 2005-03-11 23:04:40
|
In message <423...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Nicholas Nethercote wrote:
>
> > It's definitely worth aiming at. I certainly want to get unit testing
> > up and run the unit tests both natively and under V. (vgtest_ume.c
> > was a first attempt at that, although it's unfortunately broken on
> > many machines).
> >
> > As for V-on-V'ing the whole suite, who knows? I wonder how long it
> > would take :) We could add another line to the .vgtest files that
> > specifies if the regtest is suitable for V-on-V'ing.
>
> The biggest problem with V-on-V'ing is that if the outer Valgrind
> replaces malloc (ie, memcheck, addrcheck, etc), then you can only run
> tools which also do so on the inner Valgrind. So you can run memcheck
> on massif, but not on nulgrind.
I noticed that when I tried it this afternoon.
> I haven't fully worked out why, but I'm sure its related to the fact
> that the outer Valgrind sees too deeply. That is, if you have the
> command line "Vouter Vinner Client", then Vouter sees all the syscalls
> done by both Vinner and Client; if Client loads libc, then both Vinner
> *and* Vouter start doing intercepts on it (with Vouter also intercepting
> Vinner's own libc usage). It would be nice to have a mechanism whereby
> Vouter can be convinced to look for symbol info in Vinner's direct
> mmaps, and not Vinner's mmaps on behalf of the client, but I'm not sure
> exactly how that would work. (Fortunately Vouter doesn't see the
> Client's client requests; that would get really messy.)
I assumed that the problem was just that the inner valgrind wasn't
clearing the outer valgrind's entries from LD_PRELOAD but it sounds
like you've looked at it and there is more to it than that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-11 23:22:09
|
Tom Hughes wrote:
>I assumed that the problem was just that the inner valgrind wasn't
>clearing the outer valgrind's entries from LD_PRELOAD but it sounds
>like you've looked at it and there is more to it than that.
>
>
There's definitely more to it than that, but it could be a factor.
J
|