This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB and shared libraries
- To: Stephen Smith <ischis2 at home dot com>, gdb at sourceware dot cygnus dot com
- Subject: Re: GDB and shared libraries
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 26 Feb 2001 16:35:06 -0700
- References: <3A84136A.23BAF90F@home.com> <1010209182220.ZM4621@localhost.localdomain> <3A845A56.5EF8F61@home.com> <3A9AB471.5F46554@home.com> <1010226205415.ZM30678@localhost.localdomain> <3A9ADDF4.FD998D6E@home.com>
On Feb 26, 3:51pm, Stephen Smith wrote:
> > Last October, I made some changes to GDB's infrastructure to better
> > support debugging of shared libraries in an embedded environment.
> > But this infrastructure work will only really work for an SVR4-like
> > shared library implementation (which, BTW, is what Linux uses).
> >
> > See http://sources.redhat.com/ml/gdb-patches/2000-10/msg00142.html
>
> Ok, when I run "$target-gcc -E -dM -x c /dev/null" I get
>
> #define __PPC__ 1
> #define _BIG_ENDIAN 1
> #define PPC 1
> #define __svr4__ 1
> #define __GNUC_MINOR__ 95
> #define __CHAR_UNSIGNED__ 1
> #define _ARCH_PPC 1
> #define __unix 1
> #define __unix__ 1
> #define __GNUC__ 2
> #define _CALL_SYSV 1
> #define __PPC 1
> #define __BIG_ENDIAN__ 1
> #define unix 1
>
> so it appears that would be a canidate.
Maybe. You'll need to dig deeper though to know if it'll really work.
For starters, you'll need to determine if your dynamic loader calls
one of the magic symbols listed in solib_break_names[] in
solib-svr4.c. Also, you'll need to verify that it exports the r_debug
struct via the mechanism used to find it by locate_base() in
solib-svr4.c. In a nutshell, this means that the contents of the
.dynamic section as found on the target needs to have the value
corresponding to the DT_DEBUG tag be the address of the r_debug
struct.
> Which would you recommend:
> a) Patching my current code (the 5.0 release)
> b) Getting the latest snapshot
Get the latest snapshot.
However, you ought to first verify that your shared library
implementation is SVR4-like enough for it to help. (See above.)
If it doesn't, you can take one of two approaches:
1) Modify your shared library implementation so that solib-svr4.c
(in the gdb sources) will work for you. Recall that in private
email I suggested defining SVR4_FETCH_LINK_MAP_OFFSETS for your
target. This is easy to do; just take a look at struct
r_debug and struct link_map and figure out the offsets from
the beginning of the struct to each member n the struct.
Then construct a small function to fill in the fields of
GDB's struct link_map_offsets. You may even be able to
use the example at
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00147.html
verbatim.
2) Add a solib-yourtarget.c backend. There are now two examples
in the sources: solib-svr4.c and solib-aix5.c. The eventual
goal is to migrate the other shared library support to use this
framework too. (So don't look at the other shared library support
that hasn't been migrated yet. Or if you do, don't do it that
way ;-)
Kevin