This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 0/2] Let's discuss moving gdbserver to top-level


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]