Re: [Valgrind-users] Re: Re: memcheck failing to hook __builtin_new (Debian Woody)

[Salvador E. T. <sal...@in...>]

Sergey Vlasov wrote:

>On Mon, 10 May 2004 16:38:18 -0300, Salvador Eduardo Tropea wrote:
>
> =20
>
>>In this system __builtin_* are from libgcc.a
>>   =20
>>
>
>libstdc++-libc6.2-2.so.3 might still export them (it does so here,
>although the symbols are weak so they can be overridden by the program).=

> =20
>
Ok. In this case I verified that all the __builtin_* symbols included in =

the binary come from libgcc.a. Here is text from the map file generated=20
by ld:

 .text          0x080ff820       0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opdel.o)
                0x080ff820                __builtin_delete
 .text          0x080ff8c0      0x150=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opnew.o)
                0x080ff8c0                __builtin_new
 .text          0x080ffa10       0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opvdel.o)
                0x080ffa10                __builtin_vec_delete
 .text          0x080ffab0       0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opvnew.o)
                0x080ffab0                __builtin_vec_new

>>>Is your program linked with shared libstdc++ library?  This should hap=
pen
>>>automatically if g++ (not gcc) is called for linking.
>>>=20
>>>
>>>     =20
>>>
>>Yes:
>>
>>$ ldd /usr/src/setedit/makes/editor.exe
>>        librhtv.so.2.0.3 =3D> /usr/lib/librhtv.so.2.0.3 (0x4001a000)
>>   =20
>>
>
>And how is this library linked (apply ldd to it)?
> =20
>
$ ldd /usr/lib/librhtv.so.2.0.3
        libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x400d6000)
        libXmu.so.6 =3D> /usr/X11R6/lib/libXmu.so.6 (0x401b0000)
        libgpm.so.1 =3D> /usr/lib/libgpm.so.1 (0x401c5000)
        libncurses.so.5 =3D> /lib/libncurses.so.5 (0x401cb000)
        libstdc++-libc6.2-2.so.3 =3D> /usr/lib/libstdc++-libc6.2-2.so.3=20
(0x40209000)
        libm.so.6 =3D> /lib/libm.so.6 (0x40252000)
        libc.so.6 =3D> /lib/libc.so.6 (0x40273000)
        libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x40390000)
        libSM.so.6 =3D> /usr/X11R6/lib/libSM.so.6 (0x403da000)
        libICE.so.6 =3D> /usr/X11R6/lib/libICE.so.6 (0x403e2000)
        libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x403f9000)
        /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
Tell me if you need more info about the way it was linked.

>I have reproduced something similar by linking a (dummy) shared library
>with gcc -shared (so it would get an internal copy of referenced builtin=
s)
>and then linking a program against it with g++.  If the shared library w=
as
>linked with g++ -shared, all worked OK - the single copy in libstdc++ wa=
s
>used.
> =20
>
I can=C2=B4t follow you. Do you mean that the problem could be created by=
=20
mixing gcc and g++ calls?

SET

--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013