Re: -fipa-cp-clone and valgrind

[Ian Lance Taylor <iant at google dot com>]

Ryan Hill <dirtyepic@gentoo.org> writes:

> I recently hit an error while building valgrind-3.4.0 with -O3 using
> trunk (-r144460):
>
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I../coregrind -I..
> -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux
> -I../include -I../VEX/pub -DVG_PLATFORM="\"x86-linux\"" -DVGA_x86=1
> -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/usr/lib64/valgrind"\"
> -m32 -fno-stack-protector -O2 -g -Wmissing-prototypes -Wall -Wshadow
> -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
> -Wno-format-zero-length -fno-strict-aliasing -O3 -march=core2 -pipe
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -MT libcoregrind_x86_linux_a-m_libcassert.o -MD
> -MP -MF .deps/libcoregrind_x86_linux_a-m_libcassert.Tpo -c -o
> libcoregrind_x86_linux_a-m_libcassert.o `test -f 'm_libcassert.c' ||
> echo
>
> './'`m_libcassert.c m_libcassert.c: Assembler messages:
> m_libcassert.c:140: Error: symbol `m_libcassert_get_ip' is already
> defined
> make[3]: *** [libcoregrind_x86_linux_a-m_libcassert.o] Error 1
> make[3]: Leaving directory
> `/var/tmp/portage/dev-util/valgrind-3.4.0/work/valgrind-3.4.0/coregrind'      
>
>
> The error was narrowed down to the use of -fipa-cp-clone.
>
> The code in question is:
>
>   48 #if defined(VGP_x86_linux)
>   49 #  define GET_REAL_PC_SP_AND_FP(pc, sp, fp)      \
>   50       asm("call m_libcassert_get_ip;" \
>   51           "m_libcassert_get_ip: popl %0;" \
>   52           "movl %%esp, %1;" \
>   53           "movl %%ebp, %2;" \
>   54           : "=r" (pc),\
>   55             "=r" (sp),\
>   56             "=r" (fp));
>
>
> My question is, is this expected?  Is this a gcc bug, a valgrind bug,
> or the natural result of me doing something silly like trying to
> compile valgrind w/ -O3?

I would say that this is a valgrind bug, a misuse of inline asm.  gcc
never promises that it will only emit one instance of the asm,
especially if, as here, the asm is not volatile.  Instead of using a
symbol name, the code should use a forward label, as in
    call 1f;
    1: popl %0
Or it should use some other technique to ensure a unique name.

Ian