Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
Subject: Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
Date: Mon, 03 Jun 2019 16:30:00 -0000	[thread overview]
Message-ID: <87ftoqocm8.fsf@tromey.com> (raw)
In-Reply-To: <5e3c0a94-773c-4ea7-0d25-87c5273c52f5@simark.ca> (Simon Marchi's	message of "Mon, 3 Jun 2019 10:27:26 -0400")

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> Just some questions about how things will work after such a move (at least, how it
Simon> is in your branch).

Simon> I suppose that there will be a top-level --enable-gdbserver/--disable-gdbserver.
Simon> switch like there is for other components?

Yes.  This is provided automatically by the top-level configure.

Simon> If so, what happens if you do something like
Simon>   ./configure --host=x86 --target=arm --enable-gdb --enable-gdbserver
Simon> ?  Currently, if the host and target architectures are different, gdbserver won't be built
Simon> (this check is done in gdb/configure.ac:2181).

I forgot to implement any logic to disable gdbserver in the cross
scenario.  I will be sure to do that before submitting the series.

Simon> Is gdbserver silently skipped, or does it error out saying that you can't enable gdbserver
Simon> if host != target?

I'm not sure what it should do in this situation.  Maybe erroring out is
best, since it is a user error to do this.

The basic idea here, though, is to turn gdbserver from something special
with its own instructions into something that can be treated like the
other top-level directories.

Simon> Do you know about anything else in the binutils-gdb tree that is
Simon> built to run on the target?

Nope.

Tom


  reply	other threads:[~2019-06-03 16:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 21:30 Tom Tromey
2019-05-30 21:30 ` [RFC 1/2] Remove linux-waitpid.c debugging code Tom Tromey
2019-06-03 14:57   ` Simon Marchi
2019-06-03 16:32     ` Tom Tromey
2019-06-05  9:32       ` Pedro Alves
2019-05-30 21:30 ` [RFC 2/2] Move gdb's xmalloc and friends to new file Tom Tromey
2019-06-03 15:03   ` Simon Marchi
2019-06-03 16:33     ` Tom Tromey
2019-06-05  9:40   ` Pedro Alves
2019-06-05 22:33     ` Tom Tromey
2019-06-17 15:45   ` Alan Hayward
2019-06-17 17:43     ` Tom Tromey
2019-06-17 18:37       ` Pedro Alves
2019-06-18  9:31         ` Alan Hayward
2019-07-03 16:18           ` Alan Hayward
2019-07-13 16:04             ` Tom Tromey
2019-07-16 19:47             ` Pedro Alves
2019-06-03 10:24 ` [RFC 0/2] Let's discuss moving gdbserver to top-level Alan Hayward
2019-06-03 14:27 ` Simon Marchi
2019-06-03 16:30   ` Tom Tromey [this message]
2019-06-05  9:16 ` Pedro Alves

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=87ftoqocm8.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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