RFC: --enable-targets=<list>

RFC: --enable-targets=<list>

[Andrew Cagney]

Hello,

I'm getting ready to commit a patch (raw draft attached) that makes it 
possible to build a GDB that contains several orthogonal target 
architectures.  Not sure what happens when you use it yet :-)

Anyway, I'm trying to take a softly softly approach.  The attatched 
configury tweek tries to do the right thing (multi-arch when possible) 
and warn the user when something isn't possible.  The alternative would 
be to simply fail.  Thoughts?

Until someone comes up with something better, GDB will link in just the 
primary target's simulator.

As a preliminary change, I intend updating all the pure- multi-arch 
targets so that they set gdb_tdepfiles in configure.tgt instead of 
TDEPFILES=... in *.mt.  The patch currently interprets that to mean a 
multi-arch target, perhaphs I shouldn't do that?

	Andrew
From fnasser@redhat.com Sun Jul 15 19:40:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sources.redhat.com
Subject: Re: Moving sizeof.exp:get_sizeof() in lib/gdb.exp
Date: Sun, 15 Jul 2001 19:40:00 -0000
Message-id: <3B52536F.C0B4940E@redhat.com>
References: <3B07AFCF.211DC3BF@worldnet.fr> <3B1E4253.4030801@cygnus.com> <3B515C7B.D7C1D0D2@worldnet.fr>
X-SW-Source: 2001-07/msg00172.html
Content-length: 1423

Stephane Carrez wrote:
> 
> Hi Andrew and Fernando,
> 
> For the following patchs:
> 
> [RFA]: Fix gdb.base/long_long.exp for targets with 2-byte pointers

I understand why you need this here...

> [RFA]: Fix gdb.base/remote for embedded targets (HC11)

... but not here.  Are you sure this second one is related?

> 
> Andrew suggested to use the `sizeof.exp:get_sizeof()' procedure.
> 
> Rather than duplicating this procedure in several .exp file, would you
> agree to put it in lib/gdb.exp?
> 
> I can submit a patch if this looks reasonable.
> 
>         Stephane

I think Andrew meat "do like" sizeof.exp:get_sizeof()....  We usually
either pass or fail after we send commands to GDB so we know if
something (and what) went wrong.

Moving  sizeof.exp:get_sizeof()  to gdb.exp would litter that file even
more (I am already thinking of taking some time to reorganize it).  It
would also leave the sizeof.exp a little bit orphan of it.  Also,
someone can easily misuse it and generate duplicate test ids.

Your patch to long_long.exp is almost fine -- just make your test for
setting "sizeof_ptr" a little bit more robust.

Regards,
Fernando

P.S.: Have you ever resubmitted the patch for remote.exp or answered
Andrew's concerns on why you do not always "runto_main"?




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: RFC: --enable-targets=<list>

[Eli Zaretskii]

On Sun, 15 Jul 2001, Andrew Cagney wrote:

> I'm getting ready to commit a patch (raw draft attached) that makes it 
> possible to build a GDB that contains several orthogonal target 
> architectures.  Not sure what happens when you use it yet :-)
> 
> Anyway, I'm trying to take a softly softly approach.  The attatched 
> configury tweek tries to do the right thing (multi-arch when possible) 
> and warn the user when something isn't possible.  The alternative would 
> be to simply fail.  Thoughts?

I have only one thought: is it really a good idea to make this change a 
few days before you cut the release branch (if I take the tentative 
schedule seriously)?

I'm afraid of the possibility that some configurations that aren't
tested too frequently might become broken by this change, and that the 
responsible maintainers will not become aware of that until it's too 
late.

Re: RFC: --enable-targets=<list>

[Andrew Cagney]

> I have only one thought: is it really a good idea to make this change a 
> few days before you cut the release branch (if I take the tentative 
> schedule seriously)?


Thanks for reminding me, I ment to post the going-to-branch post last night.


> I'm afraid of the possibility that some configurations that aren't
> tested too frequently might become broken by this change, and that the 
> responsible maintainers will not become aware of that until it's too 
> late.


The change should only affect the d10v, m68hc11 and cris targets.  All 
of which I can cross compile.  I'm also compiling a cross debugger for 
every target listed buildable in the maintainers file.

It is however an important question.

	Andrew

Re: RFC: --enable-targets=<list>

[Stephane Carrez]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hi!

Andrew Cagney a écrit :
> 
> Hello,
> 
> I'm getting ready to commit a patch (raw draft attached) that makes it
> possible to build a GDB that contains several orthogonal target
> architectures.  Not sure what happens when you use it yet :-)
> 

Apart from the simulator, there will be a problem with the tm_print_insn
function.  There is only one, and the first _init_tdep that is called
will install its own.

I tried to have a look some day and see if we could use the opcodes generic
entry point but I stopped because there was some more work with some targets.


> Anyway, I'm trying to take a softly softly approach.  The attatched
> configury tweek tries to do the right thing (multi-arch when possible)
> and warn the user when something isn't possible.  The alternative would
> be to simply fail.  Thoughts?
> 
> Until someone comes up with something better, GDB will link in just the
> primary target's simulator.
> 
> As a preliminary change, I intend updating all the pure- multi-arch
> targets so that they set gdb_tdepfiles in configure.tgt instead of
> TDEPFILES=... in *.mt.  The patch currently interprets that to mean a
> multi-arch target, perhaphs I shouldn't do that?
> 
I'll be happy to test that.

	Stephane