Symbol tables for separately linked pieces

Symbol tables for separately linked pieces

[Paul Koning]

I have an application that consists of two parts, a main program which
is one ELF image and a subsystem which is separately linked as an ELF
image of its own.  The latter is loade into a portion of the address
space of the former at startup.  The symbol table of the subsystem
image reflects its final load address.

The question is how to handle this with GDB.  I've used the
add-symbol-file command, and that works up to a point.

The difficulty lies in the reason why the subsystem is separately
linked int he first place -- it has name conflicts with symbols in the
main program.

What I need to be able to do is this:

1. When debugging in the subsystem, have its symbol table loaded "on
   top" -- so any name lookups are resolved first from that symbol
   table and only after that from the other (main program) table.

2. When I switch to debugging in the main program, I want to be able
   to tell GDB to deactivate the subsystem symbol table temporarily
   (or perhaps better yet, keep it around "on the bottom") so a
   name that exists in both is now resolved from the main program.

I've hacked up something like this by "context switching" the
object_files and symfile_objfile variables, but that seems to be a bit
fragile.  I sometimes run into GDB internal errors with this approach.

So the questions are:

1. Does GDB have a way to do this?
2. If not, any hints about a clean way to add this?
3. If I were to add this, would it be of general interest (i.e.,
   something I should submit)?

Thanks,
	paul

Re: Symbol tables for separately linked pieces

[Andrew STUBBS]

Paul Koning wrote:
> 1. When debugging in the subsystem, have its symbol table loaded "on
>    top" -- so any name lookups are resolved first from that symbol
>    table and only after that from the other (main program) table.

> 2. When I switch to debugging in the main program, I want to be able
>    to tell GDB to deactivate the subsystem symbol table temporarily
>    (or perhaps better yet, keep it around "on the bottom") so a
>    name that exists in both is now resolved from the main program.

It's easy enough to switch between two sets of symbols using the 
symbol-file command:

   (gdb) symbol-file a.elf
   ....
   (gdb) symbol-file b.elf
   ....

The symbol-file command throws away all previous symbols (including 
those from add-symbol-file), and loads new ones. This way there never 
are any duplicate symbols to get in the way.

This solution is less satisfactory when the context change occurs 
frequently, so I've been wondering if there would be a better way to do 
it myself. Some sort of context sensitive thing maybe (select symbols 
from the same source as the current function symbol), or perhaps 
explicitly by name ("break a.elf:main").

Andrew

Re: Symbol tables for separately linked pieces

[Daniel Jacobowitz]

On Thu, Jul 10, 2008 at 03:55:58PM +0100, Andrew STUBBS wrote:
> This solution is less satisfactory when the context change occurs  
> frequently, so I've been wondering if there would be a better way to do  
> it myself. Some sort of context sensitive thing maybe (select symbols  
> from the same source as the current function symbol), or perhaps  
> explicitly by name ("break a.elf:main").

I don't have a suggestion, but I do have a hopeful sign: the same sort
of juggling is necessary for a multiple-process-image GDB, which
CodeSourcery's going to be working on once we're finished with
non-stop debugging and multi-process-single-image.  Whatever we come
up with will hopefully be useful for this two image scenario too.

I suspect we'll tell GDB to keep both symbol tables loaded, but have
one current.  But I haven't really thought about it (I'm working on
other things).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Symbol tables for separately linked pieces

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Thu, Jul 10, 2008 at 03:55:58PM +0100, Andrew STUBBS
 Daniel> wrote:
 >> This solution is less satisfactory when the context change occurs
 >> frequently, so I've been wondering if there would be a better way
 >> to do it myself. Some sort of context sensitive thing maybe
 >> (select symbols from the same source as the current function
 >> symbol), or perhaps explicitly by name ("break a.elf:main").

 Daniel> I don't have a suggestion, but I do have a hopeful sign: the
 Daniel> same sort of juggling is necessary for a
 Daniel> multiple-process-image GDB, which CodeSourcery's going to be
 Daniel> working on once we're finished with non-stop debugging and
 Daniel> multi-process-single-image.  Whatever we come up with will
 Daniel> hopefully be useful for this two image scenario too.

 Daniel> I suspect we'll tell GDB to keep both symbol tables loaded,
 Daniel> but have one current.  But I haven't really thought about it
 Daniel> (I'm working on other things).

Interesting,

The hack implementation I have right now is in the context of a dump
analyzer.  I do the "load both and have one current" thing.  On top of
that, I also allow the analyzer to find the current process (or any
other process) and load its symbol tables (including shared libraries,
eek).  It's not a common thing but occasionally it's nice to trace a
kernel crash all the way down into userland.

Maybe we should compare notes.

      paul

Re: Symbol tables for separately linked pieces

[Daniel Jacobowitz]

On Thu, Jul 10, 2008 at 11:55:32AM -0400, Paul Koning wrote:
> Maybe we should compare notes.

Yes - once we're rolling on that project, expect discussion on this
list :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Symbol tables for separately linked pieces

[Stan Shebs]

Daniel Jacobowitz wrote:
> On Thu, Jul 10, 2008 at 11:55:32AM -0400, Paul Koning wrote:
>   
>> Maybe we should compare notes.
>>     
>
> Yes - once we're rolling on that project, expect discussion on this
> list :-)
>   
I'm kind of creeping on it now, mostly looking at symbol table code to 
get an idea of what to change. From the user point of view, it seems 
pretty natural to extend the source-and-line concept to be 
program-and-source-and-line with lots of defaulting, just as line number 
alone has an implicit source file.

My chicken scratchings on paper tend to encourage the introduction of a 
fully general many-to-many mapping between inferior processes and 
objfiles, but I don't yet know if that is overly ambitious for this 
round of hackery.

Stan

Re: Symbol tables for separately linked pieces

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Daniel> Yes - once we're rolling on that project, expect discussion on this
Daniel> list :-)

Stan> I'm kind of creeping on it now, mostly looking at symbol table code to
Stan> get an idea of what to change. From the user point of view, it seems
Stan> pretty natural to extend the source-and-line concept to be
Stan> program-and-source-and-line with lots of defaulting, just as line
Stan> number alone has an implicit source file.

Stan> My chicken scratchings on paper tend to encourage the introduction of
Stan> a fully general many-to-many mapping between inferior processes and
Stan> objfiles, but I don't yet know if that is overly ambitious for this
Stan> round of hackery.

The earlier you can talk about your thoughts, and the more you can
say, the better.  It is ok by me if it is internally inconsistent or
missing things or whatever -- we (Red Hat) are also looking into
various debugger things and this kind of information definitely helps.

Tom

Re: Symbol tables for separately linked pieces

[Michael Snyder]

On Thu, 2008-07-10 at 10:26 -0400, Paul Koning wrote:
> I have an application that consists of two parts, a main program which
> is one ELF image and a subsystem which is separately linked as an ELF
> image of its own.  The latter is loade into a portion of the address
> space of the former at startup.  The symbol table of the subsystem
> image reflects its final load address.

As others have said, this sort of anticipates the challenges
we will face with heterogenous multi-process debugging.

My separate question is, why wouldn't your application be
suitable for a shared library?