Re: Broken remote protocol qOffsets response handling

[Andrew Cagney <ac131313@ges.redhat.com>]

PS: Suggest creating a bug [changerequest] report to track this new 
protocol extension -- qSections.

Andrew


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