|
From: Julian S. <js...@ac...> - 2005-08-26 16:24:18
|
Greetings. I've been doing some hacking :-) aimed at getting rid
of all glibc dependencies (on the ASPACEM branch, if you want to see).
So, as of 1 minute ago, I have a statically linked valgrind_memcheck
that appears to work, and which depends on no glibc symbols.
How do I know? Because I've been linking with "-nodefaultlibs -lgcc",
which causes the linker to complain if any glibc-defined symbols are
used. So I've slowly been whittling these down to zero.
Ideally I'd like the build to use these flags, since it will cause
the build to fail in an obvious way if any glibc symbols creep back in.
However: I can't get it to link with "-nodefaultlibs -lgcc". The
invokation and results are shown below. Anybody have any idea what
I should do? The no-linking-glibc-world is one I know nothing about.
(For the curious: I replaced all glibc uses by our own implementations,
apart from three which are non-essential and hard to do:
localtime_r in VG_(ctime)
ptrace in m_debugger.c
fork in m_debugger.c.
If anyone has enthusiasm to hack up standalone replacements, especially
for localtime_r, please hack on!)
J
sewardj@feenicks:~/VgASPACEM/aspacem/memcheck$
(cd ../coregrind && make) \
&& gcc -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -m32 \
-mpreferred-stack-boundary=2 -O2 -Wno-long-long -o valgrind_memcheck \
-static ../coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=0xb0000000 \
-Wl,-T,../valt_load_address.lds mac_leakcheck.o \
mac_malloc_wrappers.o mc_main.o mac_shared.o mc_translate.o \
-nodefaultlibs -lgcc
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0xc): In function
`_start':
../sysdeps/i386/elf/start.S:109: undefined reference to `__libc_csu_fini'
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:110:
undefined reference to `__libc_csu_init'
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x1d):../sysdeps/i386/elf/start.S:119:
undefined reference to `__libc_start_main'
collect2: ld returned 1 exit status
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 16:34:24
|
On Fri, 26 Aug 2005, Julian Seward wrote:
> However: I can't get it to link with "-nodefaultlibs -lgcc". The
> invokation and results are shown below. Anybody have any idea what
> I should do? The no-linking-glibc-world is one I know nothing about.
I'd try to get it working on a trivial case before plumbing it into
Valgrind. I don't even know how to do that, though:
[~/grind/trunk5] cat a.c
int main(void)
{
return 0;
}
[~/grind/trunk5] gcc -nodefaultlibs -lgcc a.c
/usr/lib/crt1.o(.text+0x1d): In function `_start':
: undefined reference to `__libc_start_main'
collect2: ld returned 1 exit status
I also tried -nostdlib
[~/grind/trunk5] gcc -nostdlib -lgcc a.c
/lusr/opt/binutils-2.15/bin/ld: warning: cannot find entry symbol
_start; defaulting to 08048094
[~/grind/trunk5] a.out
Segmentation fault
I don't know.
> (For the curious: I replaced all glibc uses by our own implementations,
> apart from three which are non-essential and hard to do:
> localtime_r in VG_(ctime)
> ptrace in m_debugger.c
> fork in m_debugger.c.
> If anyone has enthusiasm to hack up standalone replacements, especially
> for localtime_r, please hack on!)
For ptrace and fork don't we just need trivial wrappers for the syscalls?
Nick
|
|
From: Tom H. <to...@co...> - 2005-08-26 16:44:02
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Fri, 26 Aug 2005, Julian Seward wrote:
>
> > (For the curious: I replaced all glibc uses by our own implementations,
> > apart from three which are non-essential and hard to do:
> > localtime_r in VG_(ctime)
> > ptrace in m_debugger.c
> > fork in m_debugger.c.
> > If anyone has enthusiasm to hack up standalone replacements, especially
> > for localtime_r, please hack on!)
>
> For ptrace and fork don't we just need trivial wrappers for the syscalls?
More or less, although fork is slightly more complicated I think
because it returns to two different threads of control.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-26 16:43:00
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> sewardj@feenicks:~/VgASPACEM/aspacem/memcheck$
> (cd ../coregrind && make) \
> && gcc -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -m32 \
> -mpreferred-stack-boundary=2 -O2 -Wno-long-long -o valgrind_memcheck \
> -static ../coregrind/libcoregrind.a \
> -Wl,-defsym,valt_load_address=0xb0000000 \
> -Wl,-T,../valt_load_address.lds mac_leakcheck.o \
> mac_malloc_wrappers.o mc_main.o mac_shared.o mc_translate.o \
> -nodefaultlibs -lgcc
>
> /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0xc): In function
> `_start':
> ../sysdeps/i386/elf/start.S:109: undefined reference to `__libc_csu_fini'
> /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:110:
> undefined reference to `__libc_csu_init'
> /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x1d):../sysdeps/i386/elf/start.S:119:
> undefined reference to `__libc_start_main'
> collect2: ld returned 1 exit status
I think you need -nostartfiles as well. At the moment it is linking
crt1.o which is trying to start the C library (it pushs the address
of main and that of those init and fini functions and then calls
__libc_start_main to start the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-26 17:18:52
|
> I think you need -nostartfiles as well.
If I add that, then it complains about a lack of "_start" but nothing
else.
So I added this to m_main.c:
//extern char _start[];
extern Int main (Int argc, HChar **argv, HChar **envp);
Int _start (Int argc, HChar **argv, HChar **envp)
{
return main(argc,argv,envp);
}
and it links. So I get a warm fuzzy feeling.
However, it segfaults at startup. Stepping through with GDB, it dies
when looking for auxv on the stack. And the args to main are obviously
bogus:
main (argc=-1073745111, argv=0x0, envp=0xbffff364) at m_main.c:2352
So I guess my crude scheme of calling main from _start ain't going to
work.
Now what? Should _start do some futzing around with the
initial stack that the kernel builds, so as to get a correct
argc/v/envp ?
J
|
|
From: Greg P. <gp...@us...> - 2005-08-26 17:43:18
|
Julian Seward writes: > However: I can't get it to link with "-nodefaultlibs -lgcc". The > invokation and results are shown below. Anybody have any idea what > I should do? The no-linking-glibc-world is one I know nothing about. > > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0xc): In function > `_start': > ../sysdeps/i386/elf/start.S:109: undefined reference to `__libc_csu_fini' > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:110: > undefined reference to `__libc_csu_init' > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x1d):../sysdeps/i386/elf/start.S:119: > undefined reference to `__libc_start_main' > collect2: ld returned 1 exit status Currently, your build is still using the default crt1.o. In crt1.o, _start() calls __libc_csu_init() and __libc_start_main(), which are probably part of glibc's initialization. You might be able to get away with providing empty versions of those functions, since your pseudo-libc does all of its initialization in Valgrind's main(). (__libc_start_main() might be expected to call main() itself; check glibc's source.) Alternatively, you could link with -nostartfiles, which will omit crt1.o completely. In that case you need your own start.S that provides a _start() function that processes auxv and calls Valgrind's main(). You'd likely want to start with gcc's start.S (the one that becomes crt1.o) and hack from there. In either case, if Valgrind has any C++ static initializers or __attribute__((constructor)) functions, you'll need to handle them yourself. I expect that there aren't any. On Mac OS X and Valgrind 2.x, I used the second solution, because the default start files there have lots of historical ugliness. -- Greg Parker gp...@us... |
|
From: Julian S. <js...@ac...> - 2005-08-26 18:16:41
|
> Alternatively, you could link with -nostartfiles, which will omit > crt1.o completely. In that case you need your own start.S that > provides a _start() function that processes auxv and calls Valgrind's > main(). Did that. It seems to work. Cool. Just committed revs 1363 and 4526. Thanks, Tom, Greg. So it looks as if statically linked, glibc-free Valgrind is a viable idea. J |
|
From: Tom H. <to...@co...> - 2005-08-26 18:29:24
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> > Alternatively, you could link with -nostartfiles, which will omit
> > crt1.o completely. In that case you need your own start.S that
> > provides a _start() function that processes auxv and calls Valgrind's
> > main().
>
> Did that. It seems to work. Cool. Just committed revs 1363 and 4526.
So I see. I was just about to post my version which does it all
in assembly:
asm("\t.globl _start\n"
"\t.type _start,@function\n"
"_start:\n"
"\tpopl %esi\n"
"\tmovl %esp, %ecx\n"
"\tand $0xfffffff0, %esp\n"
"\tmovl %esi, %eax\n"
"\tincl %eax\n"
"\tshl $2, %eax\n"
"\taddl %ecx, %eax\n"
"\tpushl %eax\n"
"\tpushl %ecx\n"
"\tpushl %esi\n"
"\tcall main\n"
"\tmov %eax, %ebx\n"
"\tmov $1, %eax\n"
"\tint $0x80\n"
"\thlt\n");
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 21:20:02
|
On Fri, 26 Aug 2005, Tom Hughes wrote: > Hmm. It's not fully working for me... The problem is that gcc is > inserting calls to memcpy to handle structure assignments and those > are then unresolved when linking. Same here. If I put in a local version of memcpy() in m_libcbase.c next to VG_(memcpy)() those errors go away. Then I'm left with a weird error involving malloc() in VEX, even though you commented that out. I don't understand it at all. N ../coregrind/libcoregrind.a(.text+0x515e): In function `vgPlain_vprintf': /u/njn/grind/aspacem/coregrind/m_libcprint.c:95: undefined reference to `memcpy' ../coregrind/libcoregrind.a(.text+0xf4c4): In function `handle_SCSS_change': /u/njn/grind/aspacem/coregrind/m_signals.c:426: undefined reference to `memcpy' ../coregrind/libcoregrind.a(.text+0x10cf7): In function `queue_signal': /u/njn/grind/aspacem/coregrind/m_signals.c:1605: undefined reference to `memcpy' ../coregrind/libcoregrind.a(.text+0x197b5): In function `vgModuleLocal_read_callframe_info_dwarf2': /u/njn/grind/aspacem/coregrind/m_debuginfo/dwarf.c:2478: undefined reference to `memcpy' ../coregrind/libcoregrind.a(.text+0x316e5): In function `build_vg_sigframe': /u/njn/grind/aspacem/coregrind/m_sigframe/sigframe-x86-linux.c:447: undefined reference to `memcpy' ../coregrind/libcoregrind.a(.text+0x31702):/u/njn/grind/aspacem/coregrind/m_sigframe/sigframe-x86-linux.c:449: more undefined references to `memcpy' follow ../coregrind/libcoregrind.a(.text+0x5d662): In function `LibVEX_Alloc': /v/filer3/v1q009/njn/grind/aspacem/VEX/priv/main/vex_util.c:108: undefined reference to `malloc' |
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 21:20:08
|
On Fri, 26 Aug 2005, Nicholas Nethercote wrote: > Then I'm left with a weird error involving malloc() in VEX, even though you > commented that out. I don't understand it at all. Ok, rebuilding Vex from scratch fixed that. I guess its dependency stuff isn't quite working. N |
|
From: Tom H. <to...@co...> - 2005-08-26 22:48:58
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Fri, 26 Aug 2005, Nicholas Nethercote wrote:
>
> > Then I'm left with a weird error involving malloc() in VEX, even though you
> > commented that out. I don't understand it at all.
>
> Ok, rebuilding Vex from scratch fixed that. I guess its dependency stuff
> isn't quite working.
It won't do on that branch - it should be fixed on the trunk though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-26 18:45:57
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > Alternatively, you could link with -nostartfiles, which will omit
> > crt1.o completely. In that case you need your own start.S that
> > provides a _start() function that processes auxv and calls Valgrind's
> > main().
>
> Did that. It seems to work. Cool. Just committed revs 1363 and 4526.
Hmm. It's not fully working for me... The problem is that gcc is
inserting calls to memcpy to handle structure assignments and those
are then unresolved when linking.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-26 22:49:57
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Fri, 26 Aug 2005, Tom Hughes wrote:
>
> > Hmm. It's not fully working for me... The problem is that gcc is
> > inserting calls to memcpy to handle structure assignments and those
> > are then unresolved when linking.
>
> Same here. If I put in a local version of memcpy() in m_libcbase.c next
> to VG_(memcpy)() those errors go away.
I did much the same thing now, and it links, but doesn't run:
--14672:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
--14672:1:main Doing scan_auxv()
--14672:1:main Preprocess command line opts
VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed.
VG_(get_memory_from_mmap): 0 bytes already allocated.
Sorry. You could try using a tool that uses less memory;
eg. addrcheck instead of memcheck.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-26 23:09:52
|
In message <2e9...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <Pin...@ch...>
> Nicholas Nethercote <nj...@cs...> wrote:
>
> > On Fri, 26 Aug 2005, Tom Hughes wrote:
> >
> > > Hmm. It's not fully working for me... The problem is that gcc is
> > > inserting calls to memcpy to handle structure assignments and those
> > > are then unresolved when linking.
> >
> > Same here. If I put in a local version of memcpy() in m_libcbase.c next
> > to VG_(memcpy)() those errors go away.
>
> I did much the same thing now, and it links, but doesn't run:
But strangely it does run for me on amd64 after I fixed up a few things...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-26 23:21:04
|
In message <2e9...@lo...>
Tom Hughes <to...@co...> wrote:
> I did much the same thing now, and it links, but doesn't run:
>
> --14672:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
> --14672:1:main Doing scan_auxv()
> --14672:1:main Preprocess command line opts
>
> VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed.
> VG_(get_memory_from_mmap): 0 bytes already allocated.
This was triggered by my having a .valgrindrc file. Without it I can
get beyond that. Now it crashes if I valgrind "uname -a" but if I add
a -d switch to valgrind it works...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-27 00:25:05
|
> > VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes > > failed. VG_(get_memory_from_mmap): 0 bytes already allocated. Ah. Welcome to bootstrap allocator hell. This is what happens if you try and use VG_(malloc) before aspacemgr is able to deal with the resulting anonymous mmap. > This was triggered by my having a .valgrindrc file. Without it I can > get beyond that. Now it crashes if I valgrind "uname -a" but if I add > a -d switch to valgrind it works... I don't know if it's related, but I thought this a bit odd .. -static void _start_in_C ( Int* pArgc ) +static void _start_in_C ( ULong* pArgc ) Shouldn't that be a UWord* pArgc ? Since the location of argv/envp is determined in word-offsets from &pArgc[0], so changing it to a ULong* will screw up the computation on a 32-bit machine? J |
|
From: Julian S. <js...@ac...> - 2005-08-27 01:19:27
|
As of r4532 I believe (famous last words TM) I have now got it in a state where valgrind_memcheck will now link and work on both x86 and amd64. At least it does for me. Shout if it's still broken. J |
|
From: Tom H. <to...@co...> - 2005-08-27 15:22:35
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> (For the curious: I replaced all glibc uses by our own implementations,
> apart from three which are non-essential and hard to do:
> localtime_r in VG_(ctime)
> ptrace in m_debugger.c
> fork in m_debugger.c.
> If anyone has enthusiasm to hack up standalone replacements, especially
> for localtime_r, please hack on!)
I've done ptrace and fork now but localtime_r is harder...
The problem is time zones and daylight savings - just breaking down
the time (ie doing gmtime) is relatively easy.
I can't really see how we can sensibly do localtime_r - reading and
handling the timezone database is just going to get silly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 16:57:22
|
On Sat, 27 Aug 2005, Tom Hughes wrote:
> I can't really see how we can sensibly do localtime_r - reading and
> handling the timezone database is just going to get silly.
Perhaps we can switch to showing the number of seconds elapsed since
startup. Because people might use --trace-children=yes, we'd want a
command-line arg with which you can pass a starting value for this.
Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass
--initial-time-stamp=5 to bar so that the elapsed times were in sync.
Actually, better would be to make --time-stamp take an int (or float?)
rather than be boolean, which would avoid creating a new CLO.
How's that sound? I think it satisfies the two things people use
--time-stamp for:
- recording how long an execution took (esp. for long-running programs)
- getting the relative times of events, including with --trace-children
N
|
|
From: Tom H. <to...@co...> - 2005-08-27 18:05:09
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sat, 27 Aug 2005, Tom Hughes wrote:
>
> > I can't really see how we can sensibly do localtime_r - reading and
> > handling the timezone database is just going to get silly.
>
> Perhaps we can switch to showing the number of seconds elapsed since
> startup. Because people might use --trace-children=yes, we'd want a
> command-line arg with which you can pass a starting value for this.
> Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass
> --initial-time-stamp=5 to bar so that the elapsed times were in sync.
The only problem with that is that the reason given in the original
request (bug #70587) for wanting this was to be able to match up things
in the valgrind logs with other log files which will probably have
absolute times.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-27 19:25:59
|
On Sat, 27 Aug 2005, Tom Hughes wrote: >> Perhaps we can switch to showing the number of seconds elapsed since >> startup. Because people might use --trace-children=yes, we'd want a >> command-line arg with which you can pass a starting value for this. >> Eg. if 'foo' ran for 5 seconds and then exec'd 'bar', you'd pass >> --initial-time-stamp=5 to bar so that the elapsed times were in sync. > > The only problem with that is that the reason given in the original > request (bug #70587) for wanting this was to be able to match up things > in the valgrind logs with other log files which will probably have > absolute times. Oh. I'm out of ideas, then. N |