Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Ingham <jingham@apple.com>
To: gdb@sourceware.org
Subject: Re: How to load only selected libraries?
Date: Mon, 21 Jan 2008 18:56:00 -0000	[thread overview]
Message-ID: <3E22A5C5-689C-4E63-817F-5884D11D8838@apple.com> (raw)
In-Reply-To: <20080121031636.GB12135@caradoc.them.org>

We did this at Apple a while back.  We have a command "set  
sharedlibrary load-rules" that works like:

(gdb) help set sharedlibrary load-rules
Set the rules governing the level of symbol loading for shared  
libraries.
  * Each load rule is a triple.
  * The command takes a flattened list of triples.
  * The first two elements of the triple specify the library, by giving
       - "who loaded it" (i.e. dyld, cfm or all) in the first element,
       - and a regexp to match the library name in the second.
  * The last element specifies the level of loading for that library
       - The options are:  all, extern, container or none.

Example: To load only external symbols from all dyld-based system  
libraries, use:
     set sharedlibrary load-rules dyld ^/System/Library.* extern


The "who loaded it" is an Apple specific bit and I don't know if that  
would be relevant for any other system. Originally there were two  
loaders on Mac OS X - the CFM loader which handled modules built with  
the older classic Mac OS object file format, and dyld which handles  
the "native" mac os object file format.  We had to support CFM for a  
while because some of the larger software vendors who had Mac OS code  
bases didn't want to have to switch object file formats and OS'es at  
the same time...

The load levels have the meaning:

none - only note the FACT that the library has loaded, nothing else
container - make the section table for the library, but don't read any  
symbols
extern - roughly read the minysms for the exported functions in the  
library.  This is a little more tricky for ObjC, since there are very  
few exported symbols, all the methods are stored in ObjC runtime data  
structures, but we consider them "extern" since that's what they are  
functionally.
all - obvious

The load rules work from left to right, and the first match sets the  
state.  So you can do:

set sharedlibrary load-rules dyld ^/usr/lib/myLibrary.dylib all dyld ^/ 
usr/lib/.* extern

to load all the symbols from your library, but not for other libraries  
on the same path...

Then there's a command:

(gdb) help sharedlibrary set-load-state
Set the load level of a library (given by the index from "info  
sharedlibrary").

Whereby you modify the state.

Manually monkeying around with these states was not a very good user  
experience.  Furthermore, to get things to work right, you sometimes  
have to automatically load in symbols.  For instance, a lot of times,  
backtraces don't work very well if you don't have symbols for the  
functions in the backtrace, so if we see a shared library in a  
backtrace we auto-raise the load levels.

We found that when you have an IDE that knows the relationship between  
source files & built products, you can usually get away with setting  
all the load levels to Extern, then letting the automatic raising  
bring in symbols as you encounter them.  The one missing bit is how to  
set file & line breakpoints.  For that we added:

(gdb) break -shlib <Foo.dylib> bar.c:12

which has the dual function of restricting the breakpoint to Foo.dylib  
& also instructing gdb to load the symbols for Foo.dylib before  
setting the breakpoint.

I tried for a while to get lowering the symbol level of a library to  
work, but there are too many places in gdb - particularly if you use  
variable objects much - where objfile data is referenced.  In the end  
it didn't seem a useful enough feature to be worth the bother.

The changes are kind of all over, I don't know how useful it would be  
to look at them. But this basic model seems to have worked pretty  
well.  It certainly has made a big difference in debugging on a system  
like Mac OS X, where you generally pull in lots & lots of shlibs, many  
of which you don't at all care about...

Jim



On Jan 20, 2008, at 7:16 PM, Daniel Jacobowitz wrote:

> On Sun, Jan 20, 2008 at 05:37:32PM -0500, Srinath Avadhanula wrote:
>> I am using gdb-6.9-40-debian. Is such a feature available in a  
>> newer version?
>
> No, but I've wanted this too.
>
>
> -- 
> Daniel Jacobowitz
> CodeSourcery


  reply	other threads:[~2008-01-21 18:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-20 22:37 Srinath Avadhanula
2008-01-21  3:16 ` Daniel Jacobowitz
2008-01-21 18:56   ` Jim Ingham [this message]
2008-01-26 14:53     ` Srinath Avadhanula
2008-01-26 23:52       ` Jim Ingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E22A5C5-689C-4E63-817F-5884D11D8838@apple.com \
    --to=jingham@apple.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox