This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] Fork and Exec events with target remote
- From: Stan Shebs <stanshebs at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Don Breazeal <donb at codesourcery dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 14 Oct 2015 11:28:38 -0500
- Subject: Re: [RFC] Fork and Exec events with target remote
- Authentication-results: sourceware.org; auth=none
- References: <561810F6 dot 4050105 at codesourcery dot com> <561CDE1A dot 6080408 at redhat dot com>
On Tue, Oct 13, 2015 at 5:34 AM, Pedro Alves <palves@redhat.com> wrote:
> On 10/09/2015 08:09 PM, Don Breazeal wrote:
>> Hi
>>
>> I've been working on implementing support for fork and exec
>> events in target remote mode (as opposed to extended-remote).
[...]
>>
>> * What is the long-term plan for each of them? Will they eventually
>> merge into one?
>
> I'd very much like that to happen. It always felt to me that
> "extended" was first added as a separate target to avoid changing
> existing stubs, with the idea that things would be merged later on.
> That was all before my time, so I'm just guessing.
The original remote protocol went in even before *my* time :-) , and
there is neither changelog nor revision history from back then
offering much clue as to how it was supposed to be used, but the
design is based around a target that has gotten a signal and stopped.
Ironically, this is a better assumption for embedded development than
either the GNU OS bringup or app debugging uses for which GDB was
originally intended, and it wasn't long before Cisco and others
started burning GDB stubs into devices.
When Cygnus got a contract to support LynxOS in the early 1990s, it
was the first time we had to seriously consider the question of how to
support cross-debugging of Unix-type user programs. So we wrote
gdbserver for the target side, and on the host side, the existing
remote protocol was too limited. We did spend some time considering
extensions, but different scenarios had different problems (backwards
compatibility, user confusion, etc), plus we did not have an organized
testing regime for remote.c specifically (which is a whole backstory
of its own), so yes, it seemed more prudent to call it a new protocol
and leave the original alone as much as possible.
It has been a continuous source of user confusion ever since, and
these days we have both recognized extension and target-query
mechanisms, plus defined upgrade/obsoletion process, so I think the
two could be merged without causing too much disruption to targets
with stubs.
Stan