|
From: Gao, J. <JG...@se...> - 2003-09-24 15:49:52
|
> my_program must rely on at least one shared object.
I want to ask the reverse question: if my_program relies on one
shared object, will valgrind always work with my_program?
The reason for my question is: if the answer is yes, then we can
come up a way to "remove" (at least in practical sense) this
requirement. For example:
Ship a dummy shared object, see, vgdummy.so, with valgrind. It
has one function, see, VG_dummy() which basically does nothing. The
user program can call VG_dummy() and linked with vgdummy.so, then the
valgrind will work with the user program. We can make the VG_dummy() as
a Valgrind MACRO if desired.
Just a quick thought. Correct me if I am smoking cracks:-)
Jiafu
-----Original Message-----
From: Nicholas Nethercote [mailto:nj...@ca...]
Sent: Wednesday, September 24, 2003 11:29 AM
To: Todd Berendes
Cc: val...@li...
Subject: Re: [Valgrind-users] Valgrind ignores program if linked with
-static flag
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-24 16:00:13
|
On Wed, 24 Sep 2003, Gao, Jiafu wrote: > > my_program must rely on at least one shared object. > > I want to ask the reverse question: if my_program relies on one > shared object, will valgrind always work with my_program? > > The reason for my question is: if the answer is yes, then we can > come up a way to "remove" (at least in practical sense) this > requirement. For example: > > Ship a dummy shared object, see, vgdummy.so, with valgrind. It > has one function, see, VG_dummy() which basically does nothing. The > user program can call VG_dummy() and linked with vgdummy.so, then the > valgrind will work with the user program. We can make the VG_dummy() as > a Valgrind MACRO if desired. > > Just a quick thought. Correct me if I am smoking cracks:-) Doesn't seem like much of an improvement to me... the user still has to know about static linking causing problems. Once they know that, it's rarely(?) a problem to fix it. I think a better alternative is to use a patch Olly Betts submitted a while back: it makes Valgrind's startup script check with 'ldd' whether the program is statically linked, and aborts with a helpful explanatory message if so. Can anyone see any problems with this? If not, I'll consider committing it. N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-26 16:51:23
|
On Wed, 24 Sep 2003, Nicholas Nethercote wrote: > I think a better alternative is to use a patch Olly Betts submitted a > while back: it makes Valgrind's startup script check with 'ldd' whether > the program is statically linked, and aborts with a helpful explanatory > message if so. Can anyone see any problems with this? If not, I'll > consider committing it. Ah, I found a problem: scripts. Run 'ldd' on a script, and it says "not a dynamic executable". Or, sometimes I get lddlibc4: cannot read header from `./x' A better option might be to use 'file', and abort if the result contains the substring "statically linked". Anyone disagree? N |
|
From: Olly B. <ol...@su...> - 2003-09-26 17:09:44
|
On Fri, Sep 26, 2003 at 05:50:30PM +0100, Nicholas Nethercote wrote:
> A better option might be to use 'file', and abort if the result contains
> the substring "statically linked". Anyone disagree?
Presumably that'd fail to catch a script which started "#!/bin/sash"
(or some other statically linked interpreter)?
Not a major problem, and better than giving a bogus error for most
scripts as my patch would. But perhaps worth noting somewhere...
Cheers,
Olly
|
|
From: Tom H. <th...@cy...> - 2003-09-24 16:15:55
|
In message <9B5...@po...>
Jiafu Gao <JG...@se...> wrote:
>> my_program must rely on at least one shared object.
>
> I want to ask the reverse question: if my_program relies on one
> shared object, will valgrind always work with my_program?
Yes, because in order to rely on a shared library it must be linked
as a dynamic executable with ld-linux.so as the ELF interpreter, which
is what is actually important here.
> The reason for my question is: if the answer is yes, then we can
> come up a way to "remove" (at least in practical sense) this
> requirement. For example:
>
> Ship a dummy shared object, see, vgdummy.so, with valgrind. It
> has one function, see, VG_dummy() which basically does nothing. The
> user program can call VG_dummy() and linked with vgdummy.so, then the
> valgrind will work with the user program. We can make the VG_dummy() as
> a Valgrind MACRO if desired.
Way over the top and completely unnecessary. It's quite simple - if
you want to use valgrind don't link with -static or it won't work.
If you need to link against the static version of a particular library
then explicitly link against the .a instead of the .so for that library
and it will all work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|