RFA: Multilib support in gdb.asm tests

RFA: Multilib support in gdb.asm tests

[Nick Clifton]

Hi Guys.

  Whilst working through the GDB test results for the XScale
  processor, I discovered that the gdb.asm tests were not properly
  multi-libbed.  That is, when the armsrc1.s and asmsrc2.s files were
  assembled the multilib variations were not being taken into account.

  The patch below partially fixes this problem, at least for
  big-endian vs little-endian.  I did not go the whole hog however,
  because of the more generic problem of invoking the assembler 
  directly instead of via a compiler driver.  The problem is that when
  the assembler is invoked directly there is no chance to customise
  the assembled source code to suit the various different multilib
  options.  (In the XScale's case this meant not be able to choose
  between the ARM instruction set and the THUMB instruction set).

  I think that the correct solution to this problem is to use a
  compiler driver, but I suspect that the gdb.asm tests were intended
  to test GDBs support for debugging assembly files in the absence of
  a compiler.  Comments ?

  May I apply my patch ?

Cheers
        Nick


2002-01-11  Nick Clifton  <nickc@cambridge.redhat.com>

	* gdb.asm/asm-source.exp: Pass -EB or -EL on to the assembler
        if a big-endian or little-endian multilib option is being
        tested.

Index: gdb/testsuite/gdb.asm/asm-source.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.asm/asm-source.exp,v
retrieving revision 1.16
diff -c -3 -p -r1.16 asm-source.exp
*** asm-source.exp	2001/12/20 22:12:20	1.16
--- asm-source.exp	2002/01/11 11:58:13
*************** if { "${asm-flags}" == "" } {
*** 74,79 ****
--- 74,105 ----
      set asm-flags "-gstabs -I${srcdir}/${subdir} -I${objdir}/${subdir}"
  }
  
+ # FIXME: Invoking the assembler directly is incorrect.
+ # Although it would be good if this test could be independent of the
+ # the compiler we need it in order to ensure that we pass the correct,
+ # translated multilib options on to the assembler.
+ #
+ # For example if big-endian and little-endian multilibs are supported
+ # we may not be able to take the multilib -mbig-endian option and pass
+ # it directly to the assembler.  The spec strings in GCC may need to
+ # translate this into -EB.  For now we just hard code this translation.
+ 
+ case [target_info multilib_flags] in {
+     { *big-endian*    *-EB* *-meb* } { set asm-flags "${asm-flags} -EB" }
+     { *little-endian* *-EL* *-mel* } { set asm-flags "${asm-flags} -EL" }
+ }
+ # The "correct" thing to do is to add this line to the case statement above:
+ #
+ #   default { set asm-flags "${asm-flags} [target_info multilib_flags]" }
+ #
+ # I have not done so however because it breaks the tests for the ARM port
+ # when the THUMB multilibs are being tested.  The code in arm.inc is
+ # written in ARM not THUMB instructions, and so will not assemble if
+ # -mthumb is passed in.  Of course, if we were using GCC to drive
+ # the assembler (as we should be doing) then I could use the C pre-
+ # processor to check for the presence of a __THUMB__ define and so
+ # select the appropriate instruction sequences...
+ 
  if {[target_assemble ${src1} asmsrc1.o "${asm-flags}"] != ""} then {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }

Re: RFA: Multilib support in gdb.asm tests

[Andrew Cagney]

> Index: gdb/testsuite/gdb.asm/asm-source.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.asm/asm-source.exp,v
> retrieving revision 1.16
> diff -c -3 -p -r1.16 asm-source.exp
> *** asm-source.exp	2001/12/20 22:12:20	1.16
> --- asm-source.exp	2002/01/11 11:58:13
> *************** if { "${asm-flags}" == "" } {
> *** 74,79 ****
> --- 74,105 ----
>       set asm-flags "-gstabs -I${srcdir}/${subdir} -I${objdir}/${subdir}"
>   }
>   
> + # FIXME: Invoking the assembler directly is incorrect.


Just FYI, this is wrong.  These tests apply to targets that do not have 
a C compiler so must be able to invoke the assembler directly.

The entire motivation behind the directory is to improve the quality of 
GDB when used on assembler only targets.

enjoy,
Andrew

Re: RFA: Multilib support in gdb.asm tests

[Andrew Cagney]

> 
> The entire motivation behind the directory is to improve the quality of GDB when used on assembler only targets.


Er, no.

The entire motivation of this directory is to improve the quality of GDB 
when used on assembler.  This very much includes assembler only targets.

sorry,
Andrew

Re: RFA: Multilib support in gdb.asm tests

[Nick Clifton]

Hi Andrew,

> >   + # FIXME: Invoking the assembler directly is incorrect.
>  
> Just FYI, this is wrong.  These tests apply to targets that do not
> have a C compiler so must be able to invoke the assembler directly.

I thought that this might be the case.

What then should be done for multi-libbed targets where the multilib
options passed to the compiler are not the same as the multilib
options (if any) that get passed on to the assembler ?

BTW - was this an approval of my patch ?

Cheers
        Nick

Re: RFA: Multilib support in gdb.asm tests

[Nick Clifton]

Hi Andrew,

> >   + # FIXME: Invoking the assembler directly is incorrect.
> 
> 
> Just FYI, this is wrong.  These tests apply to targets that do not
> have a C compiler so must be able to invoke the assembler directly.

How about this alternative wording of the comment:

  # WARNING: Invoking the assembler directly is problematic.
  # For targets which support multilibs a compile time switch is used
  # to select the appropriate multilibs.  This switch may not be same
  # as the switch that the compiler will pass on to the assembler.  For
  # example if big-endian and little-endian multilibs are supported
  # the compiler options will probably be -mbig-endian and -mlittle-endian
  # but, for historical reasons, the assembler options are probably -EB
  # and -EL.
  #
  # Since these tests are supposed to be able to be run for targets for
  # which there is no compiler we cannot just invoke a compiler driver
  # program (eg 'gcc') to handle this translation for us.  For now we
  # just hard code the endian translation and hope that there are no
  # others that are needed.

Cheers
        Nick

Re: RFA: Multilib support in gdb.asm tests

[Andrew Cagney]

> Hi Andrew,
> 
> 
>> > + # FIXME: Invoking the assembler directly is incorrect.
> 
>> > Just FYI, this is wrong.  These tests apply to targets that do not
>> have a C compiler so must be able to invoke the assembler directly.
> 
> 
> I thought that this might be the case.
> 
> What then should be done for multi-libbed targets where the multilib
> options passed to the compiler are not the same as the multilib
> options (if any) that get passed on to the assembler ?


For the moment, probably something like you propose.

> BTW - was this an approval of my patch ?


No.  I'll leave that to the testsuite maintainer.

Andrew

Re: RFA: Multilib support in gdb.asm tests

[Mark Kettenis]

Nick Clifton <nickc@cambridge.redhat.com> writes:

> How about this alternative wording of the comment:
> 
>   # WARNING: Invoking the assembler directly is problematic.
>   # For targets which support multilibs a compile time switch is used
>   # to select the appropriate multilibs.  This switch may not be same
>   # as the switch that the compiler will pass on to the assembler.  For
>   # example if big-endian and little-endian multilibs are supported
>   # the compiler options will probably be -mbig-endian and -mlittle-endian
>   # but, for historical reasons, the assembler options are probably -EB
>   # and -EL.
>   #
>   # Since these tests are supposed to be able to be run for targets for
>   # which there is no compiler we cannot just invoke a compiler driver
>   # program (eg 'gcc') to handle this translation for us.  For now we
>   # just hard code the endian translation and hope that there are no
>   # others that are needed.

I'm a bit puzzled by this comment.  These tests already invoke `gcc'
for doing the final link.  Isn't that a problem too?

As an aside, using gcc for the final link is causing problems on
FreeBSD too.

Mark

Re: RFA: Multilib support in gdb.asm tests

[Michael Snyder]

Mark Kettenis wrote:
> 
> Nick Clifton <nickc@cambridge.redhat.com> writes:
> 
> > How about this alternative wording of the comment:
> >
> >   # WARNING: Invoking the assembler directly is problematic.
> >   # For targets which support multilibs a compile time switch is used
> >   # to select the appropriate multilibs.  This switch may not be same
> >   # as the switch that the compiler will pass on to the assembler.  For
> >   # example if big-endian and little-endian multilibs are supported
> >   # the compiler options will probably be -mbig-endian and -mlittle-endian
> >   # but, for historical reasons, the assembler options are probably -EB
> >   # and -EL.
> >   #
> >   # Since these tests are supposed to be able to be run for targets for
> >   # which there is no compiler we cannot just invoke a compiler driver
> >   # program (eg 'gcc') to handle this translation for us.  For now we
> >   # just hard code the endian translation and hope that there are no
> >   # others that are needed.
> 
> I'm a bit puzzled by this comment.  These tests already invoke `gcc'
> for doing the final link.  Isn't that a problem too?
> 
> As an aside, using gcc for the final link is causing problems on
> FreeBSD too.
> 

It's causing problems on Linux too.  I suspect this approach
needs to be reconsidered.

Re: RFA: Multilib support in gdb.asm tests

[Nick Clifton]

Hi Mark,

> I'm a bit puzzled by this comment.  These tests already invoke `gcc'
> for doing the final link.  Isn't that a problem too?

Actually that is the source of the problem.  Since the final link uses
'gcc' it does get the correct multilib flags.  But the assembler
sources were not being built with the appropriate 'gas' versions of
those flags.

So, for example, the assembler object files would be built with the
default endian setting, but the final link would be done with the
proper multilib endian setting.  This causes the final link to fail if
the two endian settings are not the same, (and it was this failure
that lead me to detect the problem in the first place).

Cheers
        Nick

Re: RFA: Multilib support in gdb.asm tests

[Andrew Cagney]

Just FYI,

I turned this into a bug report.  I suspect the problem will be on-going.

Andrew

Hi Andrew,


 > > + # FIXME: Invoking the assembler directly is incorrect.

 > > Just FYI, this is wrong.  These tests apply to targets that do not
 > have a C compiler so must be able to invoke the assembler directly.


I thought that this might be the case.

What then should be done for multi-libbed targets where the multilib
options passed to the compiler are not the same as the multilib
options (if any) that get passed on to the assembler ?

BTW - was this an approval of my patch ?

Cheers
         Nick