This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: shared library support hookin the remote.c
- From: "Stephen P. Smith" <ischis2 at cox dot net>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Kevin Buettner <kevinb at redhat dot com>, gdb at sources dot redhat dot com
- Date: Mon, 12 Jul 2004 17:14:49 -0700
- Subject: Re: shared library support hookin the remote.c
- References: <40AD1DA8.3090809@cox.net> <40AE69AB.7000004@cox.net> <20040611141424.2bed79f7@saguaro> <40DA349C.6080607@cox.net> <20040628134303.20e1cff0@saguaro> <40E09084.70108@cox.net> <20040628172120.2844044d@saguaro> <40E0CC21.1020401@cox.net> <20040701105812.44b85b9b@saguaro> <40E5C383.7060506@gnu.org> <40E5D0AB.7010407@cox.net> <40E5E1F6.4090203@gnu.org>
Andrew Cagney wrote:
The system that I am working on has an OS that is used for embedded
applications. Therefore the only
way to debug is by a remote protocol or by emulator. The host type
is either i686-pc-elf or
powerpc-motorola-elf
As for native on my host - usually I am running on my cygwin box and
things are working fine there.
But assuming you could, what mechanisms would you use to implement it?
:-)
Sorry, but I had to modify the old (non-gdb supported) implementation
which had a side benifit of reminding me
what needed done. Note that I am not saying that this has to be the
protocol, just that I know it works with a minimal
amount of network bandwith. Also note, that because of number 2 below,
this support is backward compatible to older
stubs or to future stubs that don't care to support shared libraries.
1) Send a packet to the remote target asking if there are any shared
libraries.
2) If the target sends back a '\0', then GDB knows that the target
doesn't support this protocol and won't
and the rest of this protocol is unused for the remainder of the
debugging session. This keeps the traffic to a
minimum for stubs that don't support shared libraries (and we have a
couple).
3) If the stub supports Step 1 it replies with a flag character. We
used '0' for none and '1' to not that there are some.
4) If a '1' is returned in Step 3, then the following happens until
there are no more libraries to report. The stub will only
return the information for one shared library at a time so as not
to over run a buffer in GDB.
- a packet is sent asking for the shared library information.
- The stub returns the library name and its location in memory
which GDB uses to then load the symbol table correctly.
There are a couple of things that should be taken into acount for remote
stubs.
1) The remote OS may not provide a way for the stub to get an
interrupt or hook the library loading code but some may. The
OS I am involved with has that code in read-only memory.
2) The OS may have already loaded the libraries by the time the stub
gets control of the the process.
It is for these two reasons that we don't use the breakpoint method that
kevin is talking about. I do like it for systems that can
support it - however.
sps
sps