Broken remote protocol qOffsets response handling

Broken remote protocol qOffsets response handling

[Earl Chew]

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.

Earl

Re: Broken remote protocol qOffsets response handling

[Daniel Jacobowitz]

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

Re: Broken remote protocol qOffsets response handling

[Andrew Cagney]

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