[PATCH,take3] Add plugin interface to LD, respun. [1..6/6]

[Dave Korn]

On 11/10/2010 18:22, Richard Henderson wrote:

> ../../git-binu/ld/ldmain.c: In function ‘add_archive_element’:
> ../../git-binu/ld/ldmain.c:800: error: unused variable ‘fildes’
> ../../git-binu/ld/ldmain.c:796: error: unused parameter ‘subsbfd’
> 
> which can be fixed in the obvious way.

  Fixed in the obvious way.

> It may be easier to avoid libiberty in the test plugin than to 
> work out how to coordinate -fpic over there without libtool too.

  Avoided.

> Please move that down to the use and add { }.

  Moved to the end and { } added.

  Plus replaced concat-and-free combination by ACONCAT.

  I found two further problems.  The ld static bootstrap test failed:

> Executing on host: sh -c {/gnu/binutils/obj.patch/ld/ld-new -m elf_i386  -o tmpdir/ld1 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /opt/gold/lib/gcc/i686-pc-linux-gnu/4.6.0/crtb
> egin.o --static tmpdir/ld-partial.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a   -lz -ldl  -L/usr/lib --start-group /opt/gold/lib/gcc/i686-pc-linux-gnu/4.6.0/libgcc.a /opt/gold/lib/gcc/i686-pc-lin
> ux-gnu/4.6.0/libgcc_eh.a -lc --end-group /opt/gold/lib/gcc/i686-pc-linux-gnu/4.6.0/crtend.o /usr/lib/crtn.o 2>&1}  /dev/null ld.tmp (timeout = 300)
> tmpdir/ld-partial.o: In function `plugin_opt_plugin':
> /gnu/binutils/src/ld/plugin.c:160: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> tmpdir/ld-partial.o: In function `plugin_opt_plugin':
> /gnu/binutils/src/ld/plugin.c:160: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> FAIL: bootstrap with --static

... and as this is caused by a warning symbol in the static libdl.a, I don't
think there's any way to turn it off, so I decided the best bet would be to
UNSUPPORTED that test for plugin-enabled builds.  Fixed in bootstrap.exp which
already skips the static link test when plugins are enabled in BFD, by also
skipping the test when plugins are enabled in LD.

  Secondly, ...

> Running /gnu/binutils/src/ld/testsuite/ld-pe/pe.exp ...
> Running /gnu/binutils/src/ld/testsuite/ld-pie/pie.exp ...
> Running /gnu/binutils/src/ld/testsuite/ld-plugin/plugin.exp ...
> ERROR: tcl error sourcing /gnu/binutils/src/ld/testsuite/ld-plugin/plugin.exp.
> ERROR: couldn't save command result in variable
>     while executing
> "catch "exec $NM tmpdir/func.o" nm_output"
>     invoked from within
> "if { ![ld_compile "$CC $CFLAGS" $srcdir/$subdir/main.c tmpdir/main.o]
> 	|| ![ld_compile "$CC $CFLAGS" $srcdir/$subdir/func.c tmpdir/func.o]
> 	|| ![ld_co..."
>     (file "/gnu/binutils/src/ld/testsuite/ld-plugin/plugin.exp" line 64)
>     invoked from within
> "source /gnu/binutils/src/ld/testsuite/ld-plugin/plugin.exp"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel #0 source /gnu/binutils/src/ld/testsuite/ld-plugin/plugin.exp"
>     invoked from within
> "catch "uplevel #0 source $test_file_name""
> Running /gnu/binutils/src/ld/testsuite/ld-powerpc/aix52.exp ...
> Running /gnu/binutils/src/ld/testsuite/ld-powerpc/powerpc.exp ...

... this turns out not to be to do with pic in libiberty or runpaths or
anything like that at all.  It happens whenever you run "make check", but not
if you run "make check RUNTESTFLAGS=plugin.exp" (I was leaving comparing full
testsuite before-and-after runs for last thing, which is why I only just had
it now).  This is because I used a variable named "nm_output" and it's
clashing in some way with the identically-named variable in ld_compile,
depending which order things get run and hence defined in, so I cut through
the whole mess and renamed it.  (It seems you're not allowed to have
identically-named local variables in separate enclosing scopes in tcl, iiuc.)

  Rebuilt and retested without regressions on i686-pc-cygwin, also verified
that it still builds when !ENABLE_PLUGINS by hacking about my config.cache to
set "ac_cv_header_dlfcn_h=no" and running "./config.status --recheck" then
"./config.status Makefile" and building.

  Rechecked the obscure targets still build, verified it didn't cause any
regressions in those parts of their testsuites that I could run without having
cross-compilers available.

  Re-tested applying the whole series one-by-one on i686-pc-linux rebuilding
and testing at each step, again no regressions, all plugin tests pass.

  Ah, there's one last thing.  I get this non-fatal warning when building on
i686-pc-linux with --enable-64-bit-bfd:

> /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I/gnu/binutils/src/ld  -I. -I/gnu/binutils/src/ld -I../bfd -I/gnu/binutils/src/ld/../bfd -I/gnu/binutils/src/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"/opt/gold/share/locale\""  -g -O2 -g -O2 -MT libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo -c -o libldtestplug_la-testplug.lo `test -f 'testplug.c' || echo '/gnu/binutils/src/ld/'`testplug.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/gnu/binutils/src/ld -I. -I/gnu/binutils/src/ld -I../bfd -I/gnu/binutils/src/ld/../bfd -I/gnu/binutils/src/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR=\"/opt/gold/share/locale\" -g -O2 -g -O2 -MT libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo -c /gnu/binutils/src/ld/testplug.c  -fPIC -DPIC -o .libs/libldtestplug_la-testplug.o
> /gnu/binutils/src/ld/testplug.c: In function ‘dump_tv_tag’:
> /gnu/binutils/src/ld/testplug.c:371:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

  It comes from this code:

>    368        case LDPT_ADD_INPUT_LIBRARY:
>    369        case LDPT_SET_EXTRA_LIBRARY_PATH:
>    370          TV_MESSAGE (LDPL_INFO, "func@0x%v\n",
>    371                          (bfd_vma)(tv->tv_u.tv_message));
>    372          break;

  With 64-bit-bfd on a 32-bit host, bfd_vma is an unsigned long long (64-bit)
int, and the tv_message is a 32-bit function pointer, so the warning is true,
but it seems pretty useless to me.  What's so bad about a cast that doesn't
lose any data?  It doesn't break the build because there's no -Werror in the
test plugin's CFLAGS, and it's of no functional consequence, so I'm not sure
whether to do anything about it.

    cheers,
      DaveK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-1-infra.diff
Type: text/x-c
Size: 54282 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-2-claimfiles-addsyms.diff
Type: text/x-c
Size: 32878 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-3-get-symbols.diff
Type: text/x-c
Size: 14990 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-4-add-files.diff
Type: text/x-c
Size: 15443 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-5-elf-vis.diff
Type: text/x-c
Size: 3606 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-plugin-api-6-libs.diff
Type: text/x-c
Size: 34986 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101013/4b023195/attachment-0005.bin>