|
From: Nicholas N. <nj...@cs...> - 2005-09-25 01:25:00
|
Hi, I've been looking at getting self-hosting working. There's a new configure flag --enable-inner which you should use with an "inner" Valgrind that you want to run under an "outer" Valgrind. It changes the load address (avoiding collisions), turns off a failing Vex sanity check, and renames the VALGRIND_LAUNCHER variable (again avoiding collisions). You should use --trace-children=yes for the outer Valgrind so as to trace into stage 2 of the inner Valgrind. You also need to use installed versions, ie. in-place builds won't work. Not sure why, maybe due to a VALGRIND_LIB collision. Depending on which combination of tools you use, it dies in various ways. But it's a start. Another odd thing is that if you use -d with both inner and outer, the inner one's output isn't produced. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-09-25 05:18:45
|
On Sat, 24 Sep 2005, Nicholas Nethercote wrote: > I've been looking at getting self-hosting working. > [...] > Another odd thing is that if you use -d with both inner > and outer, the inner one's output isn't produced. But if I change m_debuginfo.c:local_sys_write_stderr() in the inner Valgrind to use 1 (stdout) as the fd instead of 2 (stderr) the output is produced (and sent to stdout, of course). So there must be some kind of conflict in the way the two Valgrinds use stderr for debugLog printing. (And it's not, for example, caused by miscounting the -d options on the command line.) Interestingly, the other printing (eg. -v output) works without problems, and it goes to stderr as well. So something weird is happening. Nick |
|
From: Julian S. <js...@ac...> - 2005-09-25 08:57:38
|
> I've been looking at getting self-hosting working. There's a new > configure flag --enable-inner which you should use with an "inner" > Valgrind that you want to run under an "outer" Valgrind. Great stuff. > You also need to use installed versions, ie. in-place builds won't work. > Not sure why, maybe due to a VALGRIND_LIB collision. Yes ... I'm pretty sure you need to rename that one too. Apart from that I don't see why in-place builds wouldn't work. > But it's a start. Another odd thing is that if you use -d with both inner > and outer, the inner one's output isn't produced. This is due to ML_(fd_allowed) in the outer. It sees the sys_writes done by the inner on its own logfile descriptor and causes them to fail, thus making the output disappear. If you change ML_(fd_allowed) to always return True in the outer, then it works as one would expect. Problem is I can't see a clean way to fix this. ----- With r4757 in place I am able to run some stuff self-hosted: * date on none on none * date on none on cachegrind * xedit on none on none * xedit on none on cachegrind (takes ages :-) * date on memcheck on cachegrind I can't run anything on * on memcheck yet. (Well, I can, but I get flooded with errors, and later it dies: the inner client crashes, the inner exits, and the outer's leak checker bombs). So even as it stands we can use cachegrind to profile V. The first big surprise from that, running date on none on cachegrind, is that the biggest expense is in VG_(memcpy). (!) I have no idea why memcpy is so popular, but anyway: I added an extra loop to copy words rather than bytes when possible. This reduces the startup cost (of date on none) from 974 MI to 824 MI. When timed natively that's a change from 0.959s to 0.921s (3 runs of each). Apart from that cachegrind shows most of the rest of the time either in generated code or in vex, largely the register allocator and iropt. Sigh. J |
|
From: Oswald B. <os...@kd...> - 2005-09-25 09:49:18
|
On Sun, Sep 25, 2005 at 09:57:29AM +0100, Julian Seward wrote: > So even as it stands we can use cachegrind to profile V. The first big > surprise from that, running date on none on cachegrind, is that the > biggest expense is in VG_(memcpy). (!) I have no idea why memcpy is > so popular, but anyway: I added an extra loop to copy words rather than > bytes when possible. > novels have been written about optimizing string functions, in particular memcpy. mmx stuff and prefetch instructions can do wonders here (the latter at least for larger transfers). i think it would be a good idea to copy the implementations from glibc verbatim. the best is avoiding the copies in the first place, of course ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-09-25 09:58:57
|
> > But it's a start. Another odd thing is that if you use -d with both > > inner and outer, the inner one's output isn't produced. > > This is due to ML_(fd_allowed) in the outer. It sees the sys_writes > done by the inner on its own logfile descriptor and causes them to > fail, thus making the output disappear. If you change ML_(fd_allowed) > to always return True in the outer, then it works as one would expect. > Problem is I can't see a clean way to fix this. Fixed (well, kludged, anyway). See r4758. J |
|
From: Nicholas N. <nj...@cs...> - 2005-09-25 16:16:03
|
On Sun, 25 Sep 2005, Julian Seward wrote: >>> But it's a start. Another odd thing is that if you use -d with both >>> inner and outer, the inner one's output isn't produced. >> >> This is due to ML_(fd_allowed) in the outer. It sees the sys_writes >> done by the inner on its own logfile descriptor and causes them to >> fail, thus making the output disappear. If you change ML_(fd_allowed) >> to always return True in the outer, then it works as one would expect. >> Problem is I can't see a clean way to fix this. > > Fixed (well, kludged, anyway). See r4758. So the real problem is that VG_(debugLog) calls write() but doesn't check the return value. Although there's not much it could do if it did check and saw a failure. I see a similar thing running Cachegrind under Cachegrind -- the innerCG writes the output file, and then the outerCG overwrites it with it's own version! A solution would be to allow you to specify the output filename. I think that's on the Bugzilla wishlist anyway. N |
|
From: Nicholas N. <nj...@cs...> - 2005-09-25 21:01:28
|
On Sun, 25 Sep 2005, Julian Seward wrote: >>> But it's a start. Another odd thing is that if you use -d with both >>> inner and outer, the inner one's output isn't produced. >> >> This is due to ML_(fd_allowed) in the outer. It sees the sys_writes >> done by the inner on its own logfile descriptor and causes them to >> fail, thus making the output disappear. If you change ML_(fd_allowed) >> to always return True in the outer, then it works as one would expect. >> Problem is I can't see a clean way to fix this. > > Fixed (well, kludged, anyway). See r4758. Hang on, why does this block innerVG's debuglog calls, but not its normal printing? Nick |
|
From: Julian S. <js...@ac...> - 2005-09-25 22:27:55
|
On Sunday 25 September 2005 22:00, Nicholas Nethercote wrote: > On Sun, 25 Sep 2005, Julian Seward wrote: > >>> But it's a start. Another odd thing is that if you use -d with both > >>> inner and outer, the inner one's output isn't produced. > >> > >> This is due to ML_(fd_allowed) in the outer. It sees the sys_writes > >> done by the inner on its own logfile descriptor and causes them to > >> fail, thus making the output disappear. If you change ML_(fd_allowed) > >> to always return True in the outer, then it works as one would expect. > >> Problem is I can't see a clean way to fix this. > > > > Fixed (well, kludged, anyway). See r4758. > > Hang on, why does this block innerVG's debuglog calls, but not its normal > printing? I haven't got a clue. I followed the normal printing path through and it too by defaults ending up doing sys_write to stderr. Good question. J |