Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sources.redhat.com
Subject: RFC:  --enable-targets=<list>
Date: Sun, 15 Jul 2001 14:10:00 -0000	[thread overview]
Message-ID: <3B520689.1000300@cygnus.com> (raw)

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


             reply	other threads:[~2001-07-15 14:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-15 14:10 Andrew Cagney [this message]
2001-07-16  1:29 ` Eli Zaretskii
2001-07-16  8:07   ` Andrew Cagney
2001-07-17 15:18 ` Stephane Carrez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B520689.1000300@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox