This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Broken remote protocol qOffsets response handling


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]