more plugin testsuite issues

more plugin testsuite issues

[Alan Modra]

Hi Dave,
  Is there a good reason why we need $LIBS in plugin.exp:58
set libs "$LIBS $HOSTING_LIBS"

I have some partial cross toolchains installed (some without even
libc).  They all fail a number of the plugin tests due to missing -ldl
and/or -lz, which are added to LIBS via configure.in AC_SEARCH_LIBS.

In fact, using HOSTING_LIBS and HOSTING_CRT0 in plugin.exp is a little
confusing.  They are really only properly defined for native binutils
(configure.host selects on $host but uses the target $CC to figure out
startup and lib names).  Perhaps plugin.exp ought to be native only?

-- 
Alan Modra
Australia Development Lab, IBM

Re: more plugin testsuite issues

[Dave Korn]

On 26/10/2010 05:54, Alan Modra wrote:
> Hi Dave,
>   Is there a good reason why we need $LIBS in plugin.exp:58
> set libs "$LIBS $HOSTING_LIBS"

  Almost certainly not.  I verified on i686-pc-cygwin and i686-pc-linux-gnu
that nothing fails when it's removed.  Feel free to commit that change.

> I have some partial cross toolchains installed (some without even
> libc).  They all fail a number of the plugin tests due to missing -ldl
> and/or -lz, which are added to LIBS via configure.in AC_SEARCH_LIBS.
> 
> In fact, using HOSTING_LIBS and HOSTING_CRT0 in plugin.exp is a little
> confusing.  They are really only properly defined for native binutils
> (configure.host selects on $host but uses the target $CC to figure out
> startup and lib names).  Perhaps plugin.exp ought to be native only?

  It might have to be, I don't know; I don't properly understand all the ins
and outs of compiling in the testsuite.  I wanted the test to basically be the
same as doing a final link for the target platform.  That needs some kind of
crt and libs but preferably target rather than host as you so rightly point out!

  I'd like it if we could run the tests in cross as well as in native since it
only really depends on host stuff, and I could always remove the printf call
from them (or supply a stub definition somewhere), but without target libs
it's still possible for a link to fail (e.g. when a call to __main is
magically inserted at the start of main).  I don't know how to direct the
testsuite w.r.t target libs when compiling for the target using
"run_ld_link_tests".

  Hmm, maybe what would be best would be to extend the check for a compiler at
the start of plugin.exp, so that it doesn't just see if $CC is set but also
tests if it can compile a trivial exe?  Then it should just come out
unsupported on any target with no libc.

    cheers,
      DaveK

Re: more plugin testsuite issues

[Alan Modra]

On Tue, Oct 26, 2010 at 06:16:11PM +0100, Dave Korn wrote:
> On 26/10/2010 05:54, Alan Modra wrote:
> > Hi Dave,
> >   Is there a good reason why we need $LIBS in plugin.exp:58
> > set libs "$LIBS $HOSTING_LIBS"
> 
>   Almost certainly not.  I verified on i686-pc-cygwin and i686-pc-linux-gnu
> that nothing fails when it's removed.  Feel free to commit that change.

Committed.

	* ld-plugin/plugin.exp (libs): Remove $LIBS.

Index: ld/testsuite/ld-plugin/plugin.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-plugin/plugin.exp,v
retrieving revision 1.3
diff -u -p -r1.3 plugin.exp
--- ld/testsuite/ld-plugin/plugin.exp	20 Oct 2010 14:40:30 -0000	1.3
+++ ld/testsuite/ld-plugin/plugin.exp	28 Oct 2010 08:08:36 -0000
@@ -55,7 +55,7 @@ verbose "Full plugin path $plugin_path" 
 
 set testobjfiles "$HOSTING_CRT0 tmpdir/main.o tmpdir/func.o tmpdir/text.o"
 set testobjfiles_notext "$HOSTING_CRT0 tmpdir/main.o tmpdir/func.o"
-set libs "$LIBS $HOSTING_LIBS"
+set libs "$HOSTING_LIBS"
 
 set regclm "-plugin-opt registerclaimfile"
 set regas "-plugin-opt registerallsymbolsread"

-- 
Alan Modra
Australia Development Lab, IBM

Re: more plugin testsuite issues

[Dave Korn]

On 28/10/2010 09:16, Alan Modra wrote:
> On Tue, Oct 26, 2010 at 06:16:11PM +0100, Dave Korn wrote:
>> On 26/10/2010 05:54, Alan Modra wrote:
>>> Hi Dave,
>>>   Is there a good reason why we need $LIBS in plugin.exp:58
>>> set libs "$LIBS $HOSTING_LIBS"
>>   Almost certainly not.  I verified on i686-pc-cygwin and i686-pc-linux-gnu
>> that nothing fails when it's removed.  Feel free to commit that change.
> 
> Committed.
> 
> 	* ld-plugin/plugin.exp (libs): Remove $LIBS.


  Alan, did that solve everything for you, or are there still problems from
systems without libc?

  It might be easiest just to make these tests native only, like you suggested
earlier.  I would have liked to do a trial link to see if it was possible to
run the tests even in cross, but there doesn't seem to be suitable support in
the testsuite to do a generic cross link: default_ld_link is no good because
it does the 'set libs "$LIBS $HOSTING_LIBS"' thing (that's where I got it from
in the first place, btw) and default_ld_simple_link is no use because it
doesn't add any libs (or startup objects) at all.

  Ah, hang on, I just discovered ld_simple_link_defsyms.  If I use that, is it
meant to guarantee I have enough symbols defined to link an object file
without needing any crt startup objects or libraries?  Maybe all I need do is
add "__main" to the list there, and not use any (particularly $HOSTING) libs
or crt0 at all in this test.  Does that sound right?

    cheers,
      DaveK

[PATCH] Re: more plugin testsuite issues

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On 04/11/2010 16:35, Dave Korn wrote:

>   Ah, hang on, I just discovered ld_simple_link_defsyms.  If I use that, is it
> meant to guarantee I have enough symbols defined to link an object file
> without needing any crt startup objects or libraries?  Maybe all I need do is
> add "__main" to the list there, and not use any (particularly $HOSTING) libs
> or crt0 at all in this test.  Does that sound right?

  This looks better to me.  Tested natively on i686-pc-cygwin and
i686-pc-linux-gnu, and cross from i686-pc-cygwin to i686-pc-mingw32.

ld/testsuite/ChangeLog:

	* ld-plugin/plugin.exp (testobjfiles): Dont use HOSTING_CRT0.
	(testobjfiles_notext): Likewise.
	(libs): Don't use HOSTING_LIBS; fill with default symbol defs instead.

	* lib/ld-lib.exp (ld_simple_link_defsyms): Add cygming clause.

  What do you think?  OK for head?

    cheers,
      DaveK


[-- Attachment #2: plugin-test-libs-fix.diff --]
[-- Type: text/x-c, Size: 2129 bytes --]

Index: ld/testsuite/ld-plugin/plugin.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-plugin/plugin.exp,v
retrieving revision 1.4
diff -p -u -r1.4 plugin.exp
--- ld/testsuite/ld-plugin/plugin.exp	28 Oct 2010 08:16:34 -0000	1.4
+++ ld/testsuite/ld-plugin/plugin.exp	4 Nov 2010 19:42:18 -0000
@@ -53,10 +53,6 @@ set lt_objdir [regsub "objdir=" "$lt_obj
 set plugin_path "$base_dir/$lt_objdir/$plugin_name"
 verbose "Full plugin path $plugin_path" 2
 
-set testobjfiles "$HOSTING_CRT0 tmpdir/main.o tmpdir/func.o tmpdir/text.o"
-set testobjfiles_notext "$HOSTING_CRT0 tmpdir/main.o tmpdir/func.o"
-set libs "$HOSTING_LIBS"
-
 set regclm "-plugin-opt registerclaimfile"
 set regas "-plugin-opt registerallsymbolsread"
 set regcln "-plugin-opt registercleanup"
@@ -87,6 +83,12 @@ if { $can_compile && !$failed_compile } 
     }
 }
 
+set testobjfiles "tmpdir/main.o tmpdir/func.o tmpdir/text.o"
+set testobjfiles_notext "tmpdir/main.o tmpdir/func.o"
+# Rather than having libs we just define dummy values for anything
+# we may need to link a target exe; we aren't going to run it anyway.
+set libs "[ld_simple_link_defsyms] --defsym ${_}printf=0 --defsym ${_}puts=0"
+
 set plugin_tests [list \
     [list "load plugin" "-plugin $plugin_path \
     $testobjfiles $libs" "" "" {{ld plugin-1.d}} "main.x" ] \
Index: ld/testsuite/lib/ld-lib.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/lib/ld-lib.exp,v
retrieving revision 1.75
diff -p -u -r1.75 ld-lib.exp
--- ld/testsuite/lib/ld-lib.exp	14 Oct 2010 01:31:33 -0000	1.75
+++ ld/testsuite/lib/ld-lib.exp	4 Nov 2010 19:42:19 -0000
@@ -369,6 +369,11 @@ proc ld_simple_link_defsyms {} {
         append flags " --defsym __gccmain=0"
     }
 
+    # Windows targets need __main, prefixed with underscore.
+    if {[istarget *-*-cygwin* ] || [istarget *-*-mingw*]} {
+        append flags " --defsym ___main=0"
+    }
+
     # PowerPC EABI code calls __eabi.
     if {[istarget powerpc*-*-eabi*] || [istarget powerpc*-*-rtems*]} {
 	append flags " --defsym __eabi=0"

Re: [PATCH] Re: more plugin testsuite issues

[Alan Modra]

On Thu, Nov 04, 2010 at 08:11:32PM +0000, Dave Korn wrote:
> 	* ld-plugin/plugin.exp (testobjfiles): Dont use HOSTING_CRT0.
> 	(testobjfiles_notext): Likewise.
> 	(libs): Don't use HOSTING_LIBS; fill with default symbol defs instead.
> 
> 	* lib/ld-lib.exp (ld_simple_link_defsyms): Add cygming clause.
> 
>   What do you think?  OK for head?

Seems reasonable, but didn't you want to test libraries?  Not saying
you should, but figured that was why you called printf in the test.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Re: more plugin testsuite issues

[Dave Korn]

On 04/11/2010 23:54, Alan Modra wrote:
> On Thu, Nov 04, 2010 at 08:11:32PM +0000, Dave Korn wrote:
>> 	* ld-plugin/plugin.exp (testobjfiles): Dont use HOSTING_CRT0.
>> 	(testobjfiles_notext): Likewise.
>> 	(libs): Don't use HOSTING_LIBS; fill with default symbol defs instead.
>>
>> 	* lib/ld-lib.exp (ld_simple_link_defsyms): Add cygming clause.
>>
>>   What do you think?  OK for head?
> 
> Seems reasonable, but didn't you want to test libraries?  Not saying
> you should, but figured that was why you called printf in the test.

  Well yeah, that was what I wanted, but I can't see any reasonable way to do
it that's going to be portable everywhere.  We don't know what the libs or
startup objects are called for the cross-target, so we can't figure out how to
link it.  I could perhaps hack default_ld_compile around to make it possible
to omit the -c flag, and just let the cross-compiler driver do all the work, I
suppose, if you think that would be better?

    cheers,
      DaveK

Re: [PATCH] Re: more plugin testsuite issues

[Alan Modra]

On Fri, Nov 05, 2010 at 12:36:28AM +0000, Dave Korn wrote:
>   Well yeah, that was what I wanted, but I can't see any reasonable way to do
> it that's going to be portable everywhere.  We don't know what the libs or
> startup objects are called for the cross-target, so we can't figure out how to
> link it.  I could perhaps hack default_ld_compile around to make it possible
> to omit the -c flag, and just let the cross-compiler driver do all the work, I
> suppose, if you think that would be better?

No, I wouldn't bother.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Re: more plugin testsuite issues

[Dave Korn]

On 05/11/2010 03:00, Alan Modra wrote:
> On Fri, Nov 05, 2010 at 12:36:28AM +0000, Dave Korn wrote:
>>   Well yeah, that was what I wanted, but I can't see any reasonable way to do
>> it that's going to be portable everywhere.  We don't know what the libs or
>> startup objects are called for the cross-target, so we can't figure out how to
>> link it.  I could perhaps hack default_ld_compile around to make it possible
>> to omit the -c flag, and just let the cross-compiler driver do all the work, I
>> suppose, if you think that would be better?
> 
> No, I wouldn't bother.

  Is that an OK to commit then?

    cheers,
      DaveK

Re: [PATCH] Re: more plugin testsuite issues

[Alan Modra]

On Fri, Nov 05, 2010 at 04:50:18AM +0000, Dave Korn wrote:
> On 05/11/2010 03:00, Alan Modra wrote:
> > On Fri, Nov 05, 2010 at 12:36:28AM +0000, Dave Korn wrote:
> >>   Well yeah, that was what I wanted, but I can't see any reasonable way to do
> >> it that's going to be portable everywhere.  We don't know what the libs or
> >> startup objects are called for the cross-target, so we can't figure out how to
> >> link it.  I could perhaps hack default_ld_compile around to make it possible
> >> to omit the -c flag, and just let the cross-compiler driver do all the work, I
> >> suppose, if you think that would be better?
> > 
> > No, I wouldn't bother.
> 
>   Is that an OK to commit then?

Sure.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Re: more plugin testsuite issues

[Dave Korn]

On 05/11/2010 05:58, Alan Modra wrote:
> On Fri, Nov 05, 2010 at 04:50:18AM +0000, Dave Korn wrote:
>> On 05/11/2010 03:00, Alan Modra wrote:
>>> On Fri, Nov 05, 2010 at 12:36:28AM +0000, Dave Korn wrote:
>>>>   Well yeah, that was what I wanted, but I can't see any reasonable way to do
>>>> it that's going to be portable everywhere.  We don't know what the libs or
>>>> startup objects are called for the cross-target, so we can't figure out how to
>>>> link it.  I could perhaps hack default_ld_compile around to make it possible
>>>> to omit the -c flag, and just let the cross-compiler driver do all the work, I
>>>> suppose, if you think that would be better?
>>> No, I wouldn't bother.
>>   Is that an OK to commit then?
> 
> Sure.

  Done.

    cheers,
       DaveK

Re: [PATCH] Re: more plugin testsuite issues

[Andreas Schwab]

Dave Korn <dave.korn.cygwin@gmail.com> writes:

> +# Rather than having libs we just define dummy values for anything
> +# we may need to link a target exe; we aren't going to run it anyway.
> +set libs "[ld_simple_link_defsyms] --defsym ${_}printf=0 --defsym ${_}puts=0"

That does not work.

/home/andreas/src/binutils/binutils/ld/testsuite/ld-plugin/main.c:11: relocation truncated to fit: R_PPC_REL24 against symbol `puts' defined in *ABS* section in tmpdir/main.x

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Re: more plugin testsuite issues

[Alan Modra]

On Tue, Nov 16, 2010 at 11:00:09PM +0100, Andreas Schwab wrote:
> Dave Korn <dave.korn.cygwin@gmail.com> writes:
> 
> > +# Rather than having libs we just define dummy values for anything
> > +# we may need to link a target exe; we aren't going to run it anyway.
> > +set libs "[ld_simple_link_defsyms] --defsym ${_}printf=0 --defsym ${_}puts=0"
> 
> That does not work.
> 
> /home/andreas/src/binutils/binutils/ld/testsuite/ld-plugin/main.c:11: relocation truncated to fit: R_PPC_REL24 against symbol `puts' defined in *ABS* section in tmpdir/main.x

That reminds me.  I've had this in my tree for a while but hadn't
committed it.

	* ld-plugin/plugin.exp: Define printf and puts as main.

Index: ld/testsuite/ld-plugin/plugin.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-plugin/plugin.exp,v
retrieving revision 1.5
diff -u -p -r1.5 plugin.exp
--- ld/testsuite/ld-plugin/plugin.exp	5 Nov 2010 07:23:09 -0000	1.5
+++ ld/testsuite/ld-plugin/plugin.exp	16 Nov 2010 22:50:52 -0000
@@ -87,7 +87,7 @@ set testobjfiles "tmpdir/main.o tmpdir/f
 set testobjfiles_notext "tmpdir/main.o tmpdir/func.o"
 # Rather than having libs we just define dummy values for anything
 # we may need to link a target exe; we aren't going to run it anyway.
-set libs "[ld_simple_link_defsyms] --defsym ${_}printf=0 --defsym ${_}puts=0"
+set libs "[ld_simple_link_defsyms] --defsym ${_}printf=${_}main --defsym ${_}puts=${_}main"
 
 set plugin_tests [list \
     [list "load plugin" "-plugin $plugin_path \

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Re: more plugin testsuite issues

[Dave Korn]

On 16/11/2010 23:01, Alan Modra wrote:
> On Tue, Nov 16, 2010 at 11:00:09PM +0100, Andreas Schwab wrote:
>> Dave Korn <dave.korn.cygwin@gmail.com> writes:
>>
>>> +# Rather than having libs we just define dummy values for anything
>>> +# we may need to link a target exe; we aren't going to run it anyway.
>>> +set libs "[ld_simple_link_defsyms] --defsym ${_}printf=0 --defsym ${_}puts=0"
>> That does not work.
>>
>> /home/andreas/src/binutils/binutils/ld/testsuite/ld-plugin/main.c:11: relocation truncated to fit: R_PPC_REL24 against symbol `puts' defined in *ABS* section in tmpdir/main.x
> 
> That reminds me.  I've had this in my tree for a while but hadn't
> committed it.
> 
> 	* ld-plugin/plugin.exp: Define printf and puts as main.

  Ah, excellent.  That was what I was going to ask Andreas if it worked.

    cheers,
      DaveK