Re: [RFC] Fork and Exec events with target remote

On Tue, Oct 13, 2015 at 5:34 AM, Pedro Alves <[email protected]> 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