* Re: GDB and shared libraries (was Re: Are you still with Suse)
[not found] ` <1010226205415.ZM30678@localhost.localdomain>
@ 2001-02-26 14:50 ` Stephen Smith
2001-02-26 15:35 ` GDB and shared libraries Kevin Buettner
0 siblings, 1 reply; 20+ messages in thread
From: Stephen Smith @ 2001-02-26 14:50 UTC (permalink / raw)
To: gdb
Kevin Buettner 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.
Which would you recommend:
a) Patching my current code (the 5.0 release)
b) Getting the latest snapshot
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and shared libraries
2001-02-26 14:50 ` GDB and shared libraries (was Re: Are you still with Suse) Stephen Smith
@ 2001-02-26 15:35 ` Kevin Buettner
2001-02-26 16:07 ` Stephen Smith
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Kevin Buettner @ 2001-02-26 15:35 UTC (permalink / raw)
To: Stephen Smith, gdb
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and shared libraries
2001-02-26 15:35 ` GDB and shared libraries Kevin Buettner
@ 2001-02-26 16:07 ` Stephen Smith
2001-02-26 16:39 ` Stephen Smith
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Stephen Smith @ 2001-02-26 16:07 UTC (permalink / raw)
To: egcs; +Cc: gdb
>
> 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:
>
>
> 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
Since the other platform (that I have to get to work later) is x86 pe format I think I will go this route if necessary
(and then add the code back into the gdb baseline).
sps
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and shared libraries
2001-02-26 15:35 ` GDB and shared libraries Kevin Buettner
2001-02-26 16:07 ` Stephen Smith
@ 2001-02-26 16:39 ` Stephen Smith
2001-02-26 18:05 ` Kevin Buettner
2001-02-26 20:51 ` Stephen Smith
[not found] ` <3A9B0022.16ABBBE0@home.com>
3 siblings, 1 reply; 20+ messages in thread
From: Stephen Smith @ 2001-02-26 16:39 UTC (permalink / raw)
To: egcs; +Cc: gdb
I take it you meant, Modify your shared library implementation of gdb...
Is that correct?
Kevin Buettner wrote:
>
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and shared libraries
2001-02-26 16:39 ` Stephen Smith
@ 2001-02-26 18:05 ` Kevin Buettner
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Buettner @ 2001-02-26 18:05 UTC (permalink / raw)
To: Stephen Smith; +Cc: gdb
On Feb 26, 5:40pm, Stephen Smith wrote:
> Kevin Buettner wrote:
>
> >
> > 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.
>
> I take it you meant, Modify your shared library implementation of gdb...
>
> Is that correct?
No.
From your other email (including some of the private ones) it sounded
to me like you had the source to the OS and you could modify the
dynamic loader. So I meant for the above to be split up into two
parts:
a) OS / Library side work in making the dynamic loader behave
like other SVR4 shared library implementations.
b) In GDB, define SVR4_FETCH_LINK_MAP_OFFSETS for your target.
If you can do (a), then doing (b) will be trivial. If you look over
some of my past email, you'll see that I've sketched out what needs
to be done for (a).
If you end up going the other route of adding a new solib backend
for GDB, you may still end up doing some work in the dynamic loader
anyway. Basically, your dynamic loader and GDB need to agree on
an interface for 1) notifying GDB of when a shared object has been
loaded/unloaded, and 2) obtaining the names of the currently loaded
shared objects and their load addresses.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and shared libraries
2001-02-26 15:35 ` GDB and shared libraries Kevin Buettner
2001-02-26 16:07 ` Stephen Smith
2001-02-26 16:39 ` Stephen Smith
@ 2001-02-26 20:51 ` Stephen Smith
[not found] ` <3A9B0022.16ABBBE0@home.com>
3 siblings, 0 replies; 20+ messages in thread
From: Stephen Smith @ 2001-02-26 20:51 UTC (permalink / raw)
To: GDB
Let's pretend that my system is not SVR4 in nature and that I have source so a very minimal gdb server for an embedded
system that currently communicates with gdb for debugging of normal gcc applications.
Let's not assume that there are any special hooks in gdb for debugging shared libraries. What commands or data would
the gdb server have to send to gdb to enable the debugging of shared libraries.
Stephen
^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <3A9B0022.16ABBBE0@home.com>]
* gdb and shared libraries
@ 2003-07-24 21:51 wim delvaux
0 siblings, 0 replies; 20+ messages in thread
From: wim delvaux @ 2003-07-24 21:51 UTC (permalink / raw)
To: gdb
Hi all,
I am running the 5.3.90-2003_06_29-cvs-debian version of gdb and STILL i have
problems with breakpoints in shared libraries...
The problem is that you can set a breakpoint in a library but if you restart
the program all breakpoints in that library are lost (i.e. gdb knows about
them but seems to have disabled them).
Now I know that you are going to say that the library gets unloaded and hence
the breakpoint cannot be set ... but it seems that gdb tries to set them
because I get messages that It cannot set a shlib breakpoint.
Now I wonder if it is really that difficult to remember over gdb restarts that
breakpoints were set for a certain library and once that library get reloaded
set the breakpoints again.
1. without the messages that it cannot set them
2. without appearing to forget that the breakpoints were active ..
I say STILL because the problem has existed in all 5-versions I know of but
did not exist in the last 4-version.
W
^ permalink raw reply [flat|nested] 20+ messages in thread
* GDB and Shared Libraries
@ 2004-01-06 22:07 Drummonds, Scott B
2004-01-06 22:10 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Drummonds, Scott B @ 2004-01-06 22:07 UTC (permalink / raw)
To: gdb
Hi, everyone,
I'm noticing a discrepancy between the way that GDB handles shared
libraries and my Linux system does during execution. Specifically, my
program works on the command line (well, except for the actual run-time
but that I'm trying to find) but aborts in GDB for lack of shared
libraries. Specifically:
<quote>
(gdb) run <my_args>
Starting program: <my_binary> <my_args>
<my_binary>: error while loading shared libraries: libtcl8.0.so: cannot
open shared object file: No such file or directory
Program exited with code 0177.
</quote>
Can anyone tell me why this is happening? This is an old version of GDB
(5.2-2) but I can't imagine that the problem here is anything other than
my incorrect or incomplete understanding of GDB.
Thanks,
Scott
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GDB and Shared Libraries
2004-01-06 22:07 GDB and Shared Libraries Drummonds, Scott B
@ 2004-01-06 22:10 ` Daniel Jacobowitz
0 siblings, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2004-01-06 22:10 UTC (permalink / raw)
To: Drummonds, Scott B; +Cc: gdb
On Tue, Jan 06, 2004 at 02:06:57PM -0800, Drummonds, Scott B wrote:
> Hi, everyone,
>
> I'm noticing a discrepancy between the way that GDB handles shared
> libraries and my Linux system does during execution. Specifically, my
> program works on the command line (well, except for the actual run-time
> but that I'm trying to find) but aborts in GDB for lack of shared
> libraries. Specifically:
>
> <quote>
> (gdb) run <my_args>
> Starting program: <my_binary> <my_args>
> <my_binary>: error while loading shared libraries: libtcl8.0.so: cannot
> open shared object file: No such file or directory
>
> Program exited with code 0177.
> </quote>
>
> Can anyone tell me why this is happening? This is an old version of GDB
> (5.2-2) but I can't imagine that the problem here is anything other than
> my incorrect or incomplete understanding of GDB.
This usually means that you have a shell startup script (.bashrc,
.profile, et cetera) which is clobbering the library path.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 20+ messages in thread
* gdb and shared libraries
@ 2006-02-08 21:13 Patrick Alken
2006-02-09 5:54 ` Jim Blandy
0 siblings, 1 reply; 20+ messages in thread
From: Patrick Alken @ 2006-02-08 21:13 UTC (permalink / raw)
To: gdb
Hello,
I am the developer of ald (http://ald.sourceforge.net), which
is a GNU licensed debugger designed specifically for assembly
level debugging. Right now I am trying to solve the problem of
loading in the symbol tables of shared libraries for a target
program so that breakpoints can be set at addresses in these
libraries.
Unfortunately it has not been easy to find information on
how to best do this, and after studying the gdb source code
for a while I decided it was best to ask this list for help.
I am looking for a big picture with perhaps some useful
details for the more complicated steps. As an example,
1. fork + ptrace(TRACE_ME) + exec (child)
2. catch SIGTRAP (parent)
3. user types "run"
4. (start singlestepping/continuing/whatever until shared libraries
have been loaded and ?somehow? get names of all libraries
loaded by dynamic linker)
5. mmap() that list of libraries and then load their symbol tables
into memory so breakpoints can be set there
So it is step #4 that I am hoping someone on the list can give me
details for. How do you know when all the libraries have been loaded
so that you can stop execution of the program while you load
the libs symbol tables? How do you get the pathnames of the libraries
after they have been loaded so you can mmap them?
Thank you in advance,
Patrick Alken
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gdb and shared libraries
2006-02-08 21:13 gdb and shared libraries Patrick Alken
@ 2006-02-09 5:54 ` Jim Blandy
2006-02-09 13:51 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Jim Blandy @ 2006-02-09 5:54 UTC (permalink / raw)
To: Patrick Alken; +Cc: gdb
On 2/8/06, Patrick Alken <patrick.alken@colorado.edu> wrote:
> So it is step #4 that I am hoping someone on the list can give me
> details for. How do you know when all the libraries have been loaded
> so that you can stop execution of the program while you load
> the libs symbol tables? How do you get the pathnames of the libraries
> after they have been loaded so you can mmap them?
Well, each time it loads a shared library, the dynamic linker calls a
specific function (I think it's _dl_debug_state on Linux), and there
is a designated data structure for you to walk to find the current
list of shlibs. See solib.c and solib-svr4.c.
But I can't remember, nor can I Google, where this stuff is
documented. I guess we're just depending on undocumented behavior (on
Linux, at least). But the whole reason it's there is to help out the
debugger, so I don't know why it'd be undocumented.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gdb and shared libraries
2006-02-09 5:54 ` Jim Blandy
@ 2006-02-09 13:51 ` Daniel Jacobowitz
0 siblings, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2006-02-09 13:51 UTC (permalink / raw)
To: Jim Blandy; +Cc: Patrick Alken, gdb
On Wed, Feb 08, 2006 at 09:54:35PM -0800, Jim Blandy wrote:
> On 2/8/06, Patrick Alken <patrick.alken@colorado.edu> wrote:
> > So it is step #4 that I am hoping someone on the list can give me
> > details for. How do you know when all the libraries have been loaded
> > so that you can stop execution of the program while you load
> > the libs symbol tables? How do you get the pathnames of the libraries
> > after they have been loaded so you can mmap them?
>
> Well, each time it loads a shared library, the dynamic linker calls a
> specific function (I think it's _dl_debug_state on Linux), and there
> is a designated data structure for you to walk to find the current
> list of shlibs. See solib.c and solib-svr4.c.
>
> But I can't remember, nor can I Google, where this stuff is
> documented. I guess we're just depending on undocumented behavior (on
> Linux, at least). But the whole reason it's there is to help out the
> debugger, so I don't know why it'd be undocumented.
Well, that's how _we_ do it. How you're really _supposed_ to do it is
unclear, but involves the dynamic DT_DEBUG tag.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2006-02-09 13:51 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3A84136A.23BAF90F@home.com>
[not found] ` <1010209182220.ZM4621@localhost.localdomain>
[not found] ` <3A845A56.5EF8F61@home.com>
[not found] ` <3A9AB471.5F46554@home.com>
[not found] ` <1010226205415.ZM30678@localhost.localdomain>
2001-02-26 14:50 ` GDB and shared libraries (was Re: Are you still with Suse) Stephen Smith
2001-02-26 15:35 ` GDB and shared libraries Kevin Buettner
2001-02-26 16:07 ` Stephen Smith
2001-02-26 16:39 ` Stephen Smith
2001-02-26 18:05 ` Kevin Buettner
2001-02-26 20:51 ` Stephen Smith
[not found] ` <3A9B0022.16ABBBE0@home.com>
[not found] ` <1010227013252.ZM13444@ocotillo.lan>
2001-02-26 21:05 ` Stephen Smith
2001-02-26 23:10 ` Kevin Buettner
2001-02-27 7:37 ` Stephen Smith
2001-02-27 8:14 ` Andrew Cagney
2001-02-27 13:14 ` Stephen Smith
2001-02-27 13:44 ` Kevin Buettner
2001-02-27 14:04 ` Stephen Smith
2001-03-21 15:59 ` Stephen Smith
2003-07-24 21:51 gdb " wim delvaux
2004-01-06 22:07 GDB and Shared Libraries Drummonds, Scott B
2004-01-06 22:10 ` Daniel Jacobowitz
2006-02-08 21:13 gdb and shared libraries Patrick Alken
2006-02-09 5:54 ` Jim Blandy
2006-02-09 13:51 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).