|
From: Todd B. <to...@ns...> - 2003-09-24 15:20:42
|
Hi Everyone, I'm new to Valgrind, so I appologize if this is already known. I am compiling some code which links in some third party libraries (TIFF, GeoTIFF, Proj4). I wanted to link in the static (.a) libraries instead of the shared so I linked the code using the -static flag. When linked this way, Valgrind seems to ignore the program producing no valgrind output whatsoever. I recompiled the code removing the -static flag and valgrind works fine. In this process, I found that I had already removed the shared (.so) libraries anyway, so the static flag was unnecessary. So effectively, the same libraries are linked in to the code, but Valgrind does not work if -static is specified on the link line. By the way, I have been a longtime user of Purify and I must say that I am very impressed with Valgrind. Valgrind functions much like the Purify I used to use on SGI. I have Purify Plus on Linux, and it is not the same as the IRIX (SGI) version. It requires recompilation and source code modification and just plain doesn't work as well as the old IRIX version. We are mothballing our old SGI's and I was worried about what I would do about Purify. Valgrind has answered that question for me. I am not going to renew my maintanence for Purify and am switching to Valgrind. Sincerely, Todd -- __________________________________________ Todd Berendes Research Scientist National Space Science & Technology Center University of Alabama in Huntsville 320 Sparkman Drive Huntsville, AL 35805 (256) 961-7943 fax:(256) 961-7755 to...@ns... __________________________________________ |
|
From: Nicholas N. <nj...@ca...> - 2003-09-24 15:29:17
|
On Wed, 24 Sep 2003, Todd Berendes wrote:
> Valgrind does not work if -static is specified on the link line.
From the FAQ:
Q5. I try running "valgrind my_program", but my_program runs normally,
and Valgrind doesn't emit any output at all.
A5. Is my_program statically linked? Valgrind doesn't work with
statically linked binaries. my_program must rely on at least one
shared object. To determine if a my_program is statically linked,
run:
ldd my_program
It will show what shared objects my_program relies on, or say:
not a dynamic executable
if my_program is statically linked.
N
|
|
From: Steve G <lin...@ya...> - 2003-09-24 16:01:59
|
>> Valgrind does not work if -static is specified on the link line. > >From the FAQ: Remember a month or two ago someone asked about linking valgrind to their application? I bet that valgind would work for static applications if they link with valgrind. May have to create .a files instead of .so for valgrind's libs. But this would help people who only have static libraries. If that works out, maybe the FAQ could be amended for that little tip. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-09-25 08:26:24
|
On Wed, 24 Sep 2003, Steve G wrote:
> Remember a month or two ago someone asked about linking valgrind
> to their application? I bet that valgind would work for static
> applications if they link with valgrind. May have to create .a
> files instead of .so for valgrind's libs. But this would help
> people who only have static libraries.
I just tried this, but failed -- not because it can't be done, but because
I didn't know how. I have very little experience with building .a files,
can someone explain how to create .a files for valgrind.so and skin .so
files? I've included what I tried below, if that's any use.
I'm particularly interested in this because I'm wondering if it would be
possibly to run a program-linked-statically-with-Valgrind under another
copy of Valgrind, and thus valgrind Valgrind. Maybe the 2nd Valgrind
would need to have different names for all its symbols to avoid clashes,
but that would be easy to achieve because of the VG_, SK_ and other
prefixes used. There are probably other problems with my idea too, but it
would be great if it could be done...
N
----
In memcheck/Makefile I put this target:
vgskin_memcheck.a: $(vgskin_memcheck_so_OBJECTS) $(vgskin_memcheck_so_DEPENDENCIES)
@rm -f vgskin_memcheck.so$(EXEEXT)
ar crs vgskin_memcheck.a $(vgskin_memcheck_so_OBJECTS)
ranlib vgskin_memcheck.a
And in coregrind/Makefile this target:
valgrind.a: $(valgrind_so_OBJECTS) $(valgrind_so_DEPENDENCIES)
@rm -f valgrind.so
ar crs valgrind.a $(valgrind_so_OBJECTS)
ranlib valgrind.a
Then I ran "make vgskin_memcheck.a" in memcheck/, and "make valgrind.a" in
coregrind/, making the two .a files.
I then linked them with the object file of a test program, null.o:
ld -Lmemcheck -lmemcheck -Lcoregrind -lvalgrind null.o
ld warned:
ld: warning: cannot find entry symbol _start; defaulting to 08048074
When I tried running the resulting program, I got an instant seg fault.
GDB's diagnosis:
[~/grind/head6] gdb a.out core
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
[snip copyright msg]
This GDB was configured as "i386-redhat-linux-gnu"...
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000001 in ?? ()
(gdb)
|
|
From: Tom H. <th...@cy...> - 2003-09-25 08:57:17
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> I then linked them with the object file of a test program, null.o:
>
> ld -Lmemcheck -lmemcheck -Lcoregrind -lvalgrind null.o
>
> ld warned:
>
> ld: warning: cannot find entry symbol _start; defaulting to 08048074
You linked using the linker itself without linking in the C library
or the run time startup code, which is where _start will live. That
will then call main after firing up the C library.
Unless you've got a very good reason to do otherwise you're usually
better off linking with cc as that will automatically the C library
and run time startup code to the link. Try this:
cc -Lmemcheck -lmemcheck -Lcoregrind -lvalgrind null.o
If you add -v to that then you'll see all the extra things that cc
throws into the link which you were missing...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-25 09:15:13
|
On Thu, 25 Sep 2003, Tom Hughes wrote: > You linked using the linker itself without linking in the C library > or the run time startup code, which is where _start will live. That > will then call main after firing up the C library. > > Unless you've got a very good reason to do otherwise you're usually > better off linking with cc as that will automatically the C library > and run time startup code to the link. Try this: > > cc -Lmemcheck -lmemcheck -Lcoregrind -lvalgrind null.o Ah, thanks. It now compiles and runs, but Valgrind doesn't get invoked. I guess it's because the .init section in coregrind/vg_startup.S doesn't get called. Normally the "-z initfirst" flag is given to the linker when building valgrind.so... any suggestions how/when to use it when building libvalgrind.a? Can it even be done? Or is there another reason why Valgrind isn't being invoked? [If anyone manages to do this static linking, please post your instructions, that will save me stumbling along, asking questions at every step :] N ps: my list of what-I-did in my last email wasn't quite right -- some of the filenames I changed. the -lmemcheck/-lvalgrind options wouldn't have worked otherwise. |
|
From: Olly B. <ol...@su...> - 2003-09-25 10:22:25
|
On Thu, Sep 25, 2003 at 10:15:10AM +0100, Nicholas Nethercote wrote:
> It now compiles and runs, but Valgrind doesn't get invoked.
> I guess it's because the .init section in coregrind/vg_startup.S doesn't
> get called. Normally the "-z initfirst" flag is given to the linker when
> building valgrind.so... any suggestions how/when to use it when building
> libvalgrind.a?
An untested idea - try partially linking vg_startup.o so that you have a
linker invocation to pass "-z initfirst" to:
<assemble vg_startup.S to vg_startup.o>
ld -r -z initfirst vg_startup.o -o vg_startup-tmp.o
mv vg_startup-tmp.o vg_startup.o
Cheers,
Olly
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-25 10:27:57
|
On Thu, 25 Sep 2003, Olly Betts wrote: > > It now compiles and runs, but Valgrind doesn't get invoked. > > I guess it's because the .init section in coregrind/vg_startup.S doesn't > > get called. Normally the "-z initfirst" flag is given to the linker when > > building valgrind.so... any suggestions how/when to use it when building > > libvalgrind.a? > > An untested idea - try partially linking vg_startup.o so that you have a > linker invocation to pass "-z initfirst" to: > > <assemble vg_startup.S to vg_startup.o> > ld -r -z initfirst vg_startup.o -o vg_startup-tmp.o > mv vg_startup-tmp.o vg_startup.o Hmm, no luck. Maybe that's not enough, or maybe the 'initfirst' isn't the problem (or isn't the only problem)? N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-26 08:59:54
|
Hi,
Ok, I worked out how to statically link Valgrind into a program. You need
to link together:
- all the .o files in coregrind/
- all the .o files of your skin of choice (eg. memcheck/*.o)
- all the .o files of the program you are grafting Valgrind to
For example, this command will create a entirely-statically-linked program
'badX', which grafts Valgrind+Memcheck onto 'bad.o', when run from
coregrind/:
gcc -static -Winline -Wall -Wshadow -O -fomit-frame-pointer
-mpreferred-stack-boundary=2 -g -mpreferred-stack-boundary=2 -o badX
vg_scheduler.o vg_default.o vg_demangle.o vg_dispatch.o vg_errcontext.o
vg_execontext.o vg_from_ucode.o vg_hashtable.o vg_helpers.o
vg_instrument.o vg_intercept.o vg_main.o vg_malloc2.o vg_memory.o
vg_messages.o vg_mylibc.o vg_needs.o vg_procselfmaps.o vg_dummy_profile.o
vg_signals.o vg_startup.o vg_symtab2.o vg_syscalls.o vg_syscall.o
vg_to_ucode.o vg_translate.o vg_transtab.o vg_ldt.o demangle/cp-demangle.o
demangle/cplus-dem.o demangle/dyn-string.o demangle/safe-ctype.o -o badX
../memcheck/mac_leakcheck.o ../memcheck/mc_errcontext.o
../memcheck/mac_malloc_wrappers.o ../memcheck/mc_from_ucode.o
../memcheck/mac_needs.o ../memcheck/mc_helpers.o
../memcheck/mac_replace_strmem.o ../memcheck/mc_main.o
../memcheck/mc_clientreqs.o ../memcheck/mc_translate.o bad.o
vg_replace_malloc.o
'badX' now always runs under the control of the Valgrind grafted onto it.
If you remove the "-static", badX won't be entirely-statically-linked (it
relies on libc.so and ld-linux.so), but it works the same.
Before it will run, $VG_ARGS needs to be set to include a
--suppressions=something option.
I didn't use any "initfirst" arg, maybe it's just getting lucky because my
target program is so simple. I haven't tried any more complicated
programs. Still, it's at least the start of the solution for using
Valgrind on a program in an environment where you cannot use dynamic
linking.
----
And as for self-hosting... well if I run 'badX' (a not-entirely-
statically-linked version) under another copy of Valgrind (the outer
Valgrind), it runs.
And it must be tracing at least some of badX, because the outer Valgrind
died on this line in the inner Valgrind's vg_startup.S:
movl $VG_(stack)+39996 -40, %esp
because "movl imm32, %esp" wasn't supported. When I added support for
that instruction, it runs ok, and I get a bunch of errors in what looks
like generated code. But I put some deliberate value errors into the
inner Valgrind's VG_(main)(), and the outer Valgrind doesn't detect them.
So, something's working. I'm now trying to find out exactly what parts of
the inner Valgrind are being trace by the outer Valgrind. 'bad' is a
trivial program that doesn't do any mallocs, syscalls, or any of that
complicated stuff. So maybe I'm on a fool's errand. Still... it would be
ever-so-nice to valgrind Valgrind :)
N
|