Re: RFC: changes to configure.in and configure

Re: RFC: changes to configure.in and configure

[Scott Bambrough]

I generated the patch on a NetWinder running ARM Linux, then ftp'd (text mode)
the file to a Windows box to mail it.  I suspect the Window's ftp program added
the \r's.

Scott

Chris Faylor wrote:
> 
> On Mon, Jul 31, 2000 at 12:25:00PM -0400, Scott Bambrough wrote:
> >I noticed last week that gdbserver was not building on my ARM Linux box
> >automatically even though it was specified in configdirs in
> >configure.tgt.  It seems none of the modifications to configdirs in
> >configure.tgt were being applied.  I'd like to apply the following
> >patch to configure.in which fixes this problem if no on has any
> >objections.  The changes to configure are the diffs after configure was
> >regenerated using autoconf 2.13 as Andrew suggested.
> 
> When I inspect your patch I see \r's at the end of every line.  Was it
> generated on a windows system?  Or is my mail reader screwed up?
> 
> cgf

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From tonic@sequent.com Mon Jul 31 10:59:00 2000
From: "Brethour, Tanya (tonic)" <tonic@sequent.com>
To: "'gdb-patches@sourceware.cygnus.com'" <gdb-patches@sourceware.cygnus.com>
Subject: notice_signals
Date: Mon, 31 Jul 2000 10:59:00 -0000
Message-id: <166E75C06F27D211B9860000C0AE13F509396354@wembley.sequent.com>
X-SW-Source: 2000-07/msg00378.html
Content-length: 288

Hello..

I was curious if anyone knew what the notice_signals function (ie.
hpux_thread_notice_signals, child_ops_to.notice_signals,
procfs_notice_signals) is trying to accomplish. Is this needed for ALL
platforms.. or what is the criteria to tell if it is needed?

Thanks so much,
Tanya
From curtisv@lineo.com Mon Jul 31 11:17:00 2000
From: Curtis Veit <curtisv@lineo.com>
To: gdb-patches@sources.redhat.com
Subject: Trouble compiling gdb for host=i686 target=mips
Date: Mon, 31 Jul 2000 11:17:00 -0000
Message-id: <3985C227.689537B8@lineo.com>
X-SW-Source: 2000-07/msg00379.html
Content-length: 3154

Hello,

I am going to be doing a bit of work in the near future with gdb (remote
debug for
various targets.  mips, ppc, sh, and arm) so I hope  in future I might
actually do
something helpful, for today though I'm afraid  that this is mainly a
request for help.
I've been trying to figure this out for a couple days now and find I am
lost!

I seem to be having trouble compiling gdb-5.0 configured for
--host=i686-pc-linux-gnu
and
--target=mipsel-elf-linux

I am running on an AMD K7 box.

I am using stock gdb-5.0 with the mips patches by Maciej W. Rozycki from

the gdb-patches mailing list.
(also available from  ' http://www.ds2.pg.gda.pl/~macro/gdb-5.0/ '.)

I am running OpenLinux 2.3 with some updates and gcc is version
egcs-2.91.66 19990314 (egcs-1.1.2 release)

My goal is to be able to remote debug an MIPS based development board
from IDT.
With both gdbserver and gdbstubs.

I did:
  ./configure --target=mipsel-elf-linux
  make

And got the following errors:

 gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -I. -I. -I./../include
-I./../intl -I../intl -W -Wall -g -O2 -c stab-syms.c -o stab-syms.o
 echo timestamp > stab-syms.lo
 /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
-D_GNU_SOURCE     -I. -I. -I./../include  -I./../intl -I../intl   -W
-Wall -g -O2 -c elf32-mips.c
 gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -I. -I. -I./../include
-I./../intl -I../intl -W -Wall -g -O2 -c elf32-mips.c -o elf32-mips.o
 elf32-mips.c:1927: `BFD_RELOC_MIPS_HIGHER' undeclared here (not in a
function)
 elf32-mips.c:1927: initializer element for
`mips_reloc_map[21].bfd_reloc_val' is not constant
 elf32-mips.c:1928: `BFD_RELOC_MIPS_HIGHEST' undeclared here (not in a
function)
 elf32-mips.c:1928: initializer element for
`mips_reloc_map[22].bfd_reloc_val' is not constant
 make[3]: *** [elf32-mips.lo] Error 1
 make[3]: Leaving directory `/.ws/home/curtisv/gdb-5+/bfd'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/.ws/home/curtisv/gdb-5+/bfd'
 make[1]: *** [all-recursive-am] Error 2
 make[1]: Leaving directory `/.ws/home/curtisv/gdb-5+/bfd'
 make: *** [all-bfd] Error 2


I couldn't see anything wrong with the code in elf32-mips.c
(I guess I could have missed something here.)

Looking around for these declarations I find (in reloc.c)

 ENUM
   BFD_RELOC_MIPS_LITERAL
 ENUMDOC
   Relocation against a MIPS literal section.

 ENUM
   BFD_RELOC_MIPS_GOT16
 ENUMX
   BFD_RELOC_MIPS_CALL16
 ENUMEQX
   BFD_RELOC_MIPS_GPREL32
   BFD_RELOC_GPREL32
 ENUMX
   BFD_RELOC_MIPS_GOT_HI16
 ENUMX
   BFD_RELOC_MIPS_GOT_LO16
 ENUMX
   BFD_RELOC_MIPS_CALL_HI16
 ENUMX
   BFD_RELOC_MIPS_CALL_LO16
 ENUMX
   BFD_RELOC_MIPS_SUB
 ENUMX
   BFD_RELOC_MIPS_GOT_PAGE
 ENUMX
   BFD_RELOC_MIPS_GOT_OFST
 ENUMX
   BFD_RELOC_MIPS_GOT_DISP
 ENUMX
   BFD_RELOC_MIPS_HIGHER
 ENUMX
   BFD_RELOC_MIPS_HIGHEST
 COMMENT
 ENUMDOC

I have not yet figured out where ENUM, ENUMX, and friends are provided
or what they mean (although I can guess, I can't see the code) my greps
have
not provided any real insight. I'm feeling rather blind...

Does anyone know what is going on or where I should look?

Regards,
Curtis Veit
curtisv@lineo.com

Re: RFC: changes to configure.in and configure

[Scott Bambrough]

Andrew Cagney wrote:
> 
> I'm not sure how this patch:
> 
> -# else
> +else
>  # GDBserver is only useful in a "native" enviroment
> -# configdirs=`echo $configdirs | sed 's/gdbserver//'`
> +configdirs=`echo $configdirs | sed 's/gdbserver//'`
>  fi
>  changequote([,])

This bit of the patch removes gdbserver from $configdirs unless it is a native
build.

> +SUBDIRS="doc testsuite nlm $configdirs"
> +if test "${enable_multi_ice}" = "yes"; then
> +  SUBDIRS="${SUBDIRS} multi-ice"
> +fi
> +
> +AC_SUBST(SUBDIRS)
> changes things. Hmmmmm, ah this bit:
> 
> has something to do with it - be careful to not re-order code
> unnecessarily - it can hide real changes.

Yes, this is the effective part of the change.  I didn't reorder the code
unnecessarily.  This was all together in configure.in until someone added code
in between, the day before I submitted my patch.  I wonder who that was :) ?

>         o       not build gdbserver
>                 (suprize!)
> 
>         o       always configure GDBSERVER
>                 (when selected)
> 
> Your change would completly reverse this.  I don't know that that was
> the intention.

It doesn't happen.  gdbserver never gets configured without explicitly going
into the directory and configuring.  AFAIK, a target maintainer can select
gdbserver by modifying $configdirs in configure.tgt.  It can also add other
directories to configure.  This seems to be the way gdbserver is selected and
built.  It is also the way the arm embedded targets select rdi-share to be
configured and the netware targets select nlm to be configured.  Whoever made
this change broke this mechanism, while trying to prevent gdbserver from being
built.

It would be better to add --enable-gdbserver and --disable-gdbserver flags IMHO
if you wanted to selectively build gdbserver.  What do you think?

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From msnyder@redhat.com Tue Aug 01 08:04:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFC: changes to configure.in and configure
Date: Tue, 01 Aug 2000 08:04:00 -0000
Message-id: <3986E6A3.6B3C@redhat.com>
References: <3985A85C.C246C623@netwinder.org> <39863CD3.A527CEC3@cygnus.com> <3986DF7C.FCDD8A65@netwinder.org>
X-SW-Source: 2000-08/msg00008.html
Content-length: 467

Scott Bambrough wrote:
> 
> Andrew Cagney wrote:
> >
> > I'm not sure how this patch:
> >
> > -# else
> > +else
> >  # GDBserver is only useful in a "native" enviroment
> > -# configdirs=`echo $configdirs | sed 's/gdbserver//'`
> > +configdirs=`echo $configdirs | sed 's/gdbserver//'`
> >  fi
> >  changequote([,])
> 
> This bit of the patch removes gdbserver from $configdirs unless it is a native
> build.

Why?  What about host-x-host?  What about embedded linux?
From scottb@netwinder.org Tue Aug 01 08:37:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: msnyder@redhat.com
Cc: Andrew Cagney <ac131313@cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFC: changes to configure.in and configure
Date: Tue, 01 Aug 2000 08:37:00 -0000
Message-id: <3986ED4C.908168DA@netwinder.org>
References: <3985A85C.C246C623@netwinder.org> <39863CD3.A527CEC3@cygnus.com> <3986DF7C.FCDD8A65@netwinder.org> <3986E6A3.6B3C@redhat.com>
X-SW-Source: 2000-08/msg00009.html
Content-length: 869

Michael Snyder wrote:
> 
> Scott Bambrough wrote:
> >
> > This bit of the patch removes gdbserver from $configdirs unless it is a native
> > build.
> 
> Why?  What about host-x-host?  What about embedded linux?

This is why:

"Configuring gdbserver you should specify the same machine for host and
target (which are the machine that gdbserver is going to run on.  This
is not the same as the machine that gdb is going to run on; building
gdbserver automatically as part of building a whole tree of tools does
not currently work if cross-compilation is involved (we don't get the
right CC in the Makefile, to start with))."

This is a quote, from the README in the gdbserver directory.  It is the reason I
re-enabled that part of the configure code.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From taylor@cygnus.com Tue Aug 01 08:54:00 2000
From: David Taylor <taylor@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [BUG] print_address_numeric
Date: Tue, 01 Aug 2000 08:54:00 -0000
Message-id: <200008011554.LAA02265@texas.cygnus.com>
X-SW-Source: 2000-08/msg00010.html
Content-length: 4526

    Date: Tue, 01 Aug 2000 12:28:42 +1000
    From: Andrew Cagney <ac131313@cygnus.com>

    David Taylor wrote:
    > 
    > In printcmd.c (print_address_numeric), we find the lines:
    > 
    >       int ptr_bit = TARGET_PTR_BIT;
    >       if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
    >         addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
    >       print_longest (stream, 'x', use_local, (ULONGEST) addr);

    You forgot the lines:

      /* Truncate address to the size of a target pointer, avoiding shifts
	 larger or equal than the width of a CORE_ADDR.  The local
	 variable PTR_BIT stops the compiler reporting a shift overflow
	 when it won't occure. */
      /* NOTE: This assumes that the significant address information is
	 kept in the least significant bits of ADDR - the upper bits were
	 either zero or sign extended.  Should ADDRESS_TO_POINTER() or
	 some ADDRESS_TO_PRINTABLE() be used to do the conversion?  */

    :-)

Well, those lines didn't change.

With regard to the question:

    "Should ADDRESS_TO_POINTER() or some ADDRESS_TO_PRINTABLE() be used
    to do the conversion?"

ADDRESS_TO_POINTER -- no; ADDRESS_TO_PRINTABLE -- sure, but I don't need it.

    > This code has a bug, namely it assumes that addresses and pointers are
    > the same size.
    > 
    > [address == gdb representation; pointer == target representation]

	    CORE_ADDR - GDB's internal representation of an address
		    it is large enough to fit target address information.

	    pointer - targets pointer representation

	    ??? - minimum number of bits needed to represent an address on the
    target.

Currently, TARGET_PTR_BIT says how many bits pointers take in the
target representation; there is no macro / gdbarch field to say how
many bits addresses take within CORE_ADDR.

My proposed TARGET_ADDR_BIT / addr_bit is to add just such a macro /
field -- with the default value being the value of TARGET_PTR_BIT /
ptr_bit, so that targets that do nothing will work as they do now.

    When printing a symbolic address, should it be displayed using GDB's
    internal format (for MIPS definitly not) or target pointer format.

Currently, it does neither properly.  It takes the GDB representation,
and prints the number of bits that are significant on the target.

For a Harvard architecture chip, it's nice to be able to tell from the
value which address space it lives in.

For example, for the chip I'm working on, instruction memory (on the
target) is word addressed, not byte addressed.

On the target, the first instruction is at address 0, the next at
address 1, the following at address 2, and so on.

In gdb, the first instruction is at address 0x2000000, the next at
0x2000002, the following at 0x2000004, and so on.

If you set a breakpoint at 0x2000004, it will tell you it set it at
address 0x4.

I feel that it should either say

    0x2000004

('cause that is what address the user has to give to set a breakpoint
there) or

    0x2

('cause that is what address the target considers it to be).

And of the two, I feel that it should report an address that the user
would type in, namely the gdb representation, which would be 0x2000004
in this case.

Additionally, it's name suggests that it is printing an address, not a
pointer (print_address_numeric).  And, at least in my case, it is
being given an address (b->address), not a pointer.

    > For some processors they are different.  For the d10v and at least one
    > other processor, the size of a pointer is 2 bytes, but the size of an
    > address is 4 bytes.
    > 
    > I propose the creation of a new macro TARGET_ADDR_BIT, the addition of
    > the lines:
    > 
    >     #if !defined(TARGET_ADDR_BIT)
    >     #define TARGET_ADDR_BIT     TARGET_PTR_BIT
    >     #endif
    > 
    > to defs.h, and that the above lines of print_address_numeric be changed to:
    > 
    >     int addr_bit = TARGET_ADDR_BIT
    >     if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
    >       addr & ((CORE_ADDR) 1 << ptr_bit) - 1;
    >     print_longest (stream, 'x', use_local, (ULONGEST) addr);
    > 
    > Comments?

    I think it should be a method (function) rather than a macro.  The
    default function using TARGET_PTR_BIT.  It would give your target
    complete freedom over how the numeric address is printed.

	    Andrew

I have no objection to having a method (function) *in addition* to the
macro TARGET_ADDR_BIT.  But, I feel that the macro should be created
and that print_address_numeric should use it.
From fnasser@cygnus.com Tue Aug 01 08:55:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] dejagnu runtest.exp cleanup
Date: Tue, 01 Aug 2000 08:55:00 -0000
Message-id: <3986F211.3E40C5C5@cygnus.com>
References: <Pine.LNX.4.10.10007311658300.1500-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-08/msg00011.html
Content-length: 2107

Jimmy,

It is sort of standard in the current dejagnu code to look for an environment variable 
if the variable is not defined.  Is there a specific reason why you want to remove it
(like, it is conflicting with some environment variable that is frequently defined on HP)?

Can't we just leave it there for the sake of code coherence?

Thanks,
F.


Jimmy Guo wrote:
> 
> Mon Jul 31 16:45:29     Jimmy Guo       <guo@cup.hp.com>
> 
>         * runtest.exp: Cleanup reference to $env(MULTIPASS) and
>         $env(PASS).  These were added by HP but unused since.
> 
> Index: runtest.exp
> /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp
> *** runtest.exp
> --- runtest.exp Mon Jul 31 16:43:59 2000
> ***************
> *** 1604,1623 ****
> 
>       if { [info exists MULTIPASS] } {
>         set multipass $MULTIPASS
> -     } elseif {[info exists env(MULTIPASS)]} {
> -       set multipass $env(MULTIPASS)
>       }
>       if { $multipass == "" } {
>         set multipass { "" }
>       }
> 
> ! # If PASS is specified, either as a TCL variable or in environment, we
> ! # want to run only the tests specified. Its value should be a number
> ! # or a list of numbers that specify the passes that we want to run.
>       if [info exists PASS] {
>         set pass $PASS
> -     } elseif [info exists env(PASS)] {
> -       set pass $env(PASS)
>       } else {
>         set pass ""
>       }
> --- 1604,1619 ----
> 
>       if { [info exists MULTIPASS] } {
>         set multipass $MULTIPASS
>       }
>       if { $multipass == "" } {
>         set multipass { "" }
>       }
> 
> ! # If PASS is specified, we want to run only the tests specified.
> ! # Its value should be a number or a list of numbers that specify
> ! # the passes that we want to run.
>       if [info exists PASS] {
>         set pass $PASS
>       } else {
>         set pass ""
>       }

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From fnasser@cygnus.com Tue Aug 01 08:56:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] dejagnu runtest.exp misc. fixes
Date: Tue, 01 Aug 2000 08:56:00 -0000
Message-id: <3986F310.1498E68B@cygnus.com>
References: <Pine.LNX.4.10.10007311659130.1500-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-08/msg00012.html
Content-length: 3658

Jimmy,

Can you elaborate on how one would use this.  What happens today and what
will happen after this change? Can you give an example, please?

Thanks,
F.



Jimmy Guo wrote:
> 
> Mon Jul 31 16:54:52     Jimmy Guo       <guo@cup.hp.com>
> 
>         * runtest.exp: Handle multiple directories in TCL variables
>         dir_to_run and cmdline_dir_to_run; limit *.exp find to
>         one directory level to avoid foo/bar/baz.exp getting tested
>         twice (when ${dir} is 'foo', and when ${dir} is 'foo/bar').
> 
> Index: runtest.exp
> /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp
> *** runtest.exp
> --- runtest.exp Mon Jul 31 16:54:33 2000
> ***************
> *** 1734,1740 ****
>                     # value (for example in MULTIPASS) and the test
>                     # directory matches that directory.
>                     if {[info exists dir_to_run] && $dir_to_run != ""} {
> !                       if ![string match "*${dir_to_run}*" $dir] {
>                             continue
>                         }
>                     }
> --- 1734,1747 ----
>                     # value (for example in MULTIPASS) and the test
>                     # directory matches that directory.
>                     if {[info exists dir_to_run] && $dir_to_run != ""} {
> !                         set found 0
> !                         foreach directory $dir_to_run {
> !                             if [string match "*${directory}*" $dir] {
> !                                 set found 1
> !                                 break
> !                             }
> !                         }
> !                         if {!$found} {
>                             continue
>                         }
>                     }
> ***************
> *** 1744,1755 ****
>                     # directory matches that directory
>                     if {[info exists cmdline_dir_to_run] \
>                             && $cmdline_dir_to_run != ""} {
> !                       if ![string match "*${cmdline_dir_to_run}*" $dir] {
>                             continue
>                         }
>                     }
> 
> !                   foreach test_name [lsort [find ${dir} *.exp]] {
>                         if { ${test_name} == "" } {
>                             continue
>                         }
> --- 1751,1772 ----
>                     # directory matches that directory
>                     if {[info exists cmdline_dir_to_run] \
>                             && $cmdline_dir_to_run != ""} {
> !                         set found 0
> !                         foreach directory $cmdline_dir_to_run {
> !                             if [string match "*${directory}*" $dir] {
> !                                 set found 1
> !                                 break
> !                             }
> !                         }
> !                         if {!$found} {
>                             continue
>                         }
>                     }
> 
> !                   # JYG: Limit find to one level, since we don't want
> !                   # to pick up foo/bar/baz.exp twice ...
> !                   # ${test_top_dirs} includes '... foo/ foo/bar/ ...'
> !                     foreach test_name [lsort [find -maxdepth 1 ${dir} *.exp]] {
>                         if { ${test_name} == "" } {
>                             continue
>                         }

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From guo@cup.hp.com Tue Aug 01 09:35:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] dejagnu runtest.exp cleanup
Date: Tue, 01 Aug 2000 09:35:00 -0000
Message-id: <Pine.LNX.4.10.10008010932120.1500-100000@hpcll168.cup.hp.com>
References: <3986F211.3E40C5C5@cygnus.com>
X-SW-Source: 2000-08/msg00013.html
Content-length: 2504

Well some of the env variables were added by HP ... and we have since
moved to use the site.exp TCL var interface, after I learned that the
env var interface might interfere with the standard build process
(e.g. gnu make).

I'm not too strong on this ... if you think keeping these env vars
around is OK, that fine as well.

- Jimmy Guo

>It is sort of standard in the current dejagnu code to look for an environment variable 
>if the variable is not defined.  Is there a specific reason why you want to remove it
>(like, it is conflicting with some environment variable that is frequently defined on HP)?
>
>Can't we just leave it there for the sake of code coherence?
>
>Thanks,
>F.
>
>
>Jimmy Guo wrote:
>> 
>> Mon Jul 31 16:45:29     Jimmy Guo       <guo@cup.hp.com>
>> 
>>         * runtest.exp: Cleanup reference to $env(MULTIPASS) and
>>         $env(PASS).  These were added by HP but unused since.
>> 
>> Index: runtest.exp
>> /usr/local/bin/diff -c -L runtest.exp runtest.exp@@/main/cygnus/6 runtest.exp
>> *** runtest.exp
>> --- runtest.exp Mon Jul 31 16:43:59 2000
>> ***************
>> *** 1604,1623 ****
>> 
>>       if { [info exists MULTIPASS] } {
>>         set multipass $MULTIPASS
>> -     } elseif {[info exists env(MULTIPASS)]} {
>> -       set multipass $env(MULTIPASS)
>>       }
>>       if { $multipass == "" } {
>>         set multipass { "" }
>>       }
>> 
>> ! # If PASS is specified, either as a TCL variable or in environment, we
>> ! # want to run only the tests specified. Its value should be a number
>> ! # or a list of numbers that specify the passes that we want to run.
>>       if [info exists PASS] {
>>         set pass $PASS
>> -     } elseif [info exists env(PASS)] {
>> -       set pass $env(PASS)
>>       } else {
>>         set pass ""
>>       }
>> --- 1604,1619 ----
>> 
>>       if { [info exists MULTIPASS] } {
>>         set multipass $MULTIPASS
>>       }
>>       if { $multipass == "" } {
>>         set multipass { "" }
>>       }
>> 
>> ! # If PASS is specified, we want to run only the tests specified.
>> ! # Its value should be a number or a list of numbers that specify
>> ! # the passes that we want to run.
>>       if [info exists PASS] {
>>         set pass $PASS
>>       } else {
>>         set pass ""
>>       }
>
>-- 
>Fernando Nasser
>Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
>2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
>Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: RFC: changes to configure.in and configure

[Andrew Cagney]

Michael Snyder wrote:
> 
> Scott Bambrough wrote:
> >
> > Andrew Cagney wrote:
> > >
> > > I'm not sure how this patch:
> > >
> > > -# else
> > > +else
> > >  # GDBserver is only useful in a "native" enviroment
> > > -# configdirs=`echo $configdirs | sed 's/gdbserver//'`
> > > +configdirs=`echo $configdirs | sed 's/gdbserver//'`
> > >  fi
> > >  changequote([,])
> >
> > This bit of the patch removes gdbserver from $configdirs unless it is a native
> > build.
> 
> Why?  What about host-x-host?  What about embedded linux?

I think, the process of building cross comiling gdbserver should be kept
separate to the normal config/build of GDB.  Instead either:

	o	a separatly tree configured
		for a canadian cross build
		(use cross compiler to
		cross compile gdbserver)
		
	o	something very similar to newlib
		(newlib is built using the
		uninstalled cross compiler from
		the build tree)

	enjoy,
		Andrew