This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
- From: Tom Tromey <tom at tromey dot com>
- To: Simon Marchi <simark at simark dot ca>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Mon, 03 Jun 2019 10:30:23 -0600
- Subject: Re: [RFC 0/2] Let's discuss moving gdbserver to top-level
- References: <20190530213046.20542-1-tom@tromey.com> <5e3c0a94-773c-4ea7-0d25-87c5273c52f5@simark.ca>
>>>>> "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