|
From: Robert W. <rj...@du...> - 2004-08-26 17:22:49
|
Now that we've got FV, I've started removing things from vg_mylibc.c and replacing calls to them with just regular libc calls. Totally experimental - I just want to see how far I can go with this. The patch against the CVS head is at: http://www.durables.org/software/valgrind No regressions on my Fedora Core 2 box so far. If someone could apply the patch and test it on other distros, I'd appreciate it. I'll update the patch as I progress. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-08-27 16:19:48
|
On Thu, 26 Aug 2004, Robert Walsh wrote: > Now that we've got FV, I've started removing things from vg_mylibc.c and > replacing calls to them with just regular libc calls. Totally > experimental - I just want to see how far I can go with this. The patch > against the CVS head is at: > > http://www.durables.org/software/valgrind > > No regressions on my Fedora Core 2 box so far. If someone could apply > the patch and test it on other distros, I'd appreciate it. I get these compile warnings: vg_mylibc.c: In function `vgPlain_system': vg_mylibc.c:1562: warning: passing arg 2 of `execve' from incompatible pointer type vg_mylibc.c:1562: warning: passing arg 3 of `execve' from incompatible pointer type vg_syscalls.c: In function `after_kill': vg_syscalls.c:4007: warning: implicit declaration of function `getpgrp' No regressions. I appreciate the amount of crap this patch cuts -- 237 lines' worth. But I'm wary of doing this in an ad-hoc way... what restrictions do we have on using libc? I think we can't use any functions that could use brk, ie. any functions that use malloc(). Is that right? How do we know which functions satisfy that condition? N |
|
From: Robert W. <rj...@du...> - 2004-08-27 19:13:58
|
> I get these compile warnings: >=20 > vg_mylibc.c: In function `vgPlain_system': > vg_mylibc.c:1562: warning: passing arg 2 of `execve' from incompatible = pointer type > vg_mylibc.c:1562: warning: passing arg 3 of `execve' from incompatible = pointer type I couldn't figure these out right away, so I ignored them :-) They seem harmless - probably something to do with const. I'll look into it some other time. > vg_syscalls.c: In function `after_kill': > vg_syscalls.c:4007: warning: implicit declaration of function `getpgrp' Oops - I left out a header file. I will update the patch tonight. > But I'm wary of doing this in an ad-hoc way... what restrictions do we=20 > have on using libc? I think we can't use any functions that could use > brk, ie. any functions that use malloc(). Is that right? How do we know= =20 > which functions satisfy that condition? I think so. Right now, I've changed only functions that I know are trivial (i.e. foo() being essentially just a wrapper for syscall(FOO) style functions.) This means getpid() doesn't work, for example, as it appears to do some caching of the pid, which I assume fork() invalidates somehow. Idle thought: could we provide a malloc (and friends) that libc could use, that's just a wrapper around out VG_(malloc) stuff? That way we could use lots of goodies from libc, like printf, the resolver code, etc. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2004-08-27 22:01:47
|
On Fri, 2004-08-27 at 12:13 -0700, Robert Walsh wrote: > Idle thought: could we provide a malloc (and friends) that libc could > use, that's just a wrapper around out VG_(malloc) stuff? That way we > could use lots of goodies from libc, like printf, the resolver code, > etc. Very tricky, because glibc has all that nasty short-circuiting machinery. Calls internal to glibc don't use the normal dynamic linker name resolution rules, so you can't override calls to malloc, etc. Or you can override some calls, but not all... J |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 13:42:18
|
On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: >> Idle thought: could we provide a malloc (and friends) that libc could >> use, that's just a wrapper around out VG_(malloc) stuff? That way we >> could use lots of goodies from libc, like printf, the resolver code, >> etc. > > Very tricky, because glibc has all that nasty short-circuiting > machinery. Calls internal to glibc don't use the normal dynamic linker > name resolution rules, so you can't override calls to malloc, etc. Or > you can override some calls, but not all... and this kind of thing makes me wonder if there are any other nasty traps waiting inside glibc to grip us up if we start using it more... N |
|
From: Chris J. <ch...@at...> - 2004-08-29 20:43:30
|
> On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: >=20 > >> Idle thought: could we provide a malloc (and friends) that=20 > libc could=20 > >> use, that's just a wrapper around out VG_(malloc) stuff? =20 > That way we=20 > >> could use lots of goodies from libc, like printf, the=20 > resolver code,=20 > >> etc. > > > > Very tricky, because glibc has all that nasty short-circuiting=20 > > machinery. Calls internal to glibc don't use the normal dynamic=20 > > linker name resolution rules, so you can't override calls=20 > to malloc,=20 > > etc. Or you can override some calls, but not all... >=20 > and this kind of thing makes me wonder if there are any other=20 > nasty traps=20 > waiting inside glibc to grip us up if we start using it more... I wrote a skin that used a fairly large number of glibc functions that worked fine so long as I overrode malloc, free, etc. It's important to = strip out any reference to pthread_*, _pthread_* and __pthread_* symbols in = the object files though. Chris January |