Broken remote protocol qOffsets response handling

[Andrew Cagney]

> On Thu, Sep 12, 2002 at 07:13:40AM -0700, Earl Chew wrote:
> 
>> I started using qOffsets, and was dismayed to find that gdb remote.c
>> silently discards bss, and uses data twice instead.
>> 
>> Looking through the archives, I see that jtc has already posted
>> a patch to resolve this issue (both in remote.c and nlm/gdbserve.c).
>> 
>> http://sources.redhat.com/ml/gdb-patches/1999-q4/msg00011.html
>> 
>> Apparently nlm/gdbserve.c is the root of the problem (.bss and .data
>> equivalent), and the hack in remote.c basically makes qOffsets useless
>> for most every other target that could use it.
>> 
>> Is it simply too difficult to incorporate this patch?
>> 
>> If we can't, I'd propose adding qSections (exactly the same syntax
>> as qOffsets) that doesn't have this inflexible behaviour.
> 
> 
> My vote is to include it (and possibly kill the NetWare stub at the
> same time).  I don't believe this stub is in use any longer.  But it's
> not my opinion that matters :)

 From memory, qOffsets has other limitations:

- assumes only text, data, bss sections (which is a typical of elf)

- doesn't handle delayed segment moves (why Cisco added their T reply 
variant which puts the segment change info in there

So I wouldn't just clone the existing packet.

Nothing stopping you trying to eliminate NLS.  See:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC133
for the process.

Andrew