This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [v4 2/2] multi-executable support
I'm focusing on a a single item bit of the review first, as changes here
affect how to expand/rewrite the rest of the docs as well.
On Thursday 03 September 2009 19:28:43, Eli Zaretskii wrote:
> > +@smallexample
> > +(@value{GDBP}) info sspaces
> > + ?Id ? Main Program
> > + ?2 ? ?goodbye
> > + ? ? ? ?Bound inferiors: ID 1 (process 21561)
> > +* 1 ? ?hello
> > +@end smallexample
> > +
> > +Here we can see that no inferior is running the program @code{hello},
> > +while @code{process 21561} is running the program @code{goodbye}. ?On
> > +some targets, it is possible that multiple inferiors are bound to the
> > +same symbol space.
>
> So "symbol space" is actually a synonym for a "program", i.e. the set
> of code, data, and symbolic debug info that is the result of linking
> an executable? then why not call it a "program"? ?
I would like that, but I'm not sure if it is correct. If
it is, great, I'm very glad to simplify.
I actually don't know the exact definition of what is a "program".
Are the code, data, symbolic debug info of the load shared libraries
(and of other sources, e.g., added with add-symbol-file) part of the
program as well, or is the program considered the main executable
only? I had the feeling that in GDB speak, it was the latter case.
If not, I'd be glad to s/sspaces/programs/g.
Let me try to give concrete examples to show why I got to where
I am, and then I hope you'll be able to tell me (from the user's
perspective) with a stronger opinion, that I should really expose
sspaces as "programs" to the user, or not. Please be patient,
the email is long, but it's mostly just pastes of usage examples.
In its current form, if you want to run two copies of the same
executable, then you need two sspaces, and you load the same
executable into each of them. The loading can be done with
'add-symbol-space;sspace N;file EXEC', or 'add-symbol-space -exec EXEC',
or 'clone-symbol-space'. Note that even though the sspaces
end up with the same executable loaded, each instance of the program
may end up running at different addresses, e.g., due to PIE on linux,
or on embedded targets like uClinux, that relocate the main
executable, so that more than one process can run on the same
address space (no MMU). Even on a full blown OS, and even without
PIE, each running instance or the same executable, may end up loading
different shared libraries, or even the same shared libraries
at different addresses.
Here's an example. When running two instances of the shreloc
test under GDB, you'll see this:
(gdb) info sspaces
Id Main Program
2 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
Bound inferiors: ID 2 (process 21784)
* 1 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
Bound inferiors: ID 1 (process 21754)
I got there by doing:
./gdb ./testsuite/gdb.base/shreloc
(gdb) start
...
14 fn_1 (extern_var_1);
(gdb) clone-symbol-space
Added symbol space 2.
1 symbol spaces added.
(gdb) sspace 2
[Switching to sspace 2 (/home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc)]
(gdb) start
...
Temporary breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.base/shreloc.c:14
14 fn_1 (extern_var_1);
(gdb)
Initially, I did think of calling the new entity "programs", but
abandoned it, due to shared libraries (or other bits loaded with
add-symbol-file), and also due to the fact that "info program" was
already taken. But if that was a wrong decision, renaming
is easy. :-) Let me continue with the examples. Here's an
example showing that two instances of the same
executable (program?), when running have loaded the same shared
libraries at different addresses:
(gdb) info sspaces
Id Main Program
* 2 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
Bound inferiors: ID 2 (process 23932)
1 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
Bound inferiors: ID 1 (process 23911)
(gdb) info sharedlibrary
....
0x00007ffff7bdf490 0x00007ffff7bdf578 Yes /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc1.sl
0x00007ffff79de490 0x00007ffff79de578 Yes /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc2.sl
....
(gdb) sspace 1
<switched current sspace>
....
(gdb) info sharedlibrary
....
0x00007fa6c9196490 0x00007fa6c9196578 Yes /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc1.sl
0x00007fa6c8f95490 0x00007fa6c8f95578 Yes /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc2.sl
....
This impacts, e.g., breakpoints, as GDB likes to show addresses of symbolic/line breakpoints. E.g.,
(gdb) b 9
Breakpoint 5 at 0x7f3efb62352c: file ../../../src/gdb/testsuite/gdb.base/shreloc1.c, line 9. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
3 breakpoint keep y <MULTIPLE>
3.1 y 0x00007f3efb62352c in fn_1
at ../../../src/gdb/testsuite/gdb.base/shreloc1.c:9 sspace 2
3.2 y 0x00007fa6c9196533 in fn_1
at ../../../src/gdb/testsuite/gdb.base/shreloc1.c:9 sspace 1
In users' terms, you could think of a symbol spaces as
cheap gdb instances within gdb. Doing things this way
allows things like, e.g., the "file" command to work as it
always has, except that it applies to the current
sspace. E.g.,
>./gdb
(gdb) info sspaces
Id Main Program
* 1
(gdb) p main
No symbol table is loaded. Use the "file" command.
(gdb) file ./gdb
Reading symbols from /home/pedro/gdb/sspaces/build/gdb/gdb...done.
(gdb) info sspaces
Id Main Program
* 1 /home/pedro/gdb/sspaces/build/gdb/gdb
(gdb) p main
$1 = {int (int, char **)} 0x453a28 <main>
(gdb) add-symbol-space
Added symbol space 2
1 symbol spaces added.
(gdb) info sspaces
Id Main Program
2
* 1 /home/pedro/gdb/sspaces/build/gdb/gdb
(the sspace is empty)
(gdb) sspace 2
[Switching to sspace 2]
(gdb) p main
No symbol table is loaded. Use the "file" command.
(gdb) file ./gdb
Reading symbols from /home/pedro/gdb/sspaces/build/gdb/gdb...done.
(gdb) info sspaces
Id Main Program
* 2 /home/pedro/gdb/sspaces/build/gdb/gdb
1 /home/pedro/gdb/sspaces/build/gdb/gdb
(gdb) p main
$2 = {int (int, char **)} 0x453a28 <main>
Now sspace 2 is loaded with gdb's executable too. We can
change that with the all-familiar "file" command:
(gdb) file ./testsuite/gdb.base/shreloc
Load new symbol table from "/home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc"? (y or n) y
Reading symbols from /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc...done.
(gdb) info sspaces
Id Main Program
* 2 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
1 /home/pedro/gdb/sspaces/build/gdb/gdb
(gdb)
> I could easily
> understand how several inferiors can run the same program at the same
> time, you don't need to explain that.
The cases I was alluding to were parent/child after a vfork
call --- both parent and child are running in the same address space;
and all inferiors on a DICOS-like targets --- all processes see the
same set of symbols and see then at the same addresses, although
each has its own address space (and copy of data, thereof).
In the "traditional" and common case, you'll only have one inferior
bound to each sspace. This is important to keep GDB working like
it always used to. E.g., so that GDB still does queries like:
./gdb ./testsuite/gdb.base/shreloc
(gdb) start
...
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/shreloc.c:14
14 fn_1 (extern_var_1);
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n)
> In any case, the seemingly interchangeable use of these two here is
> confusing, unless it is explained where you introduce "symbol space".
What do you think by now? Shall I call this entity "program", and
ditch the distintion of program vs "symbol space" (or whatever else
it would end up being called, it was just the early name I came up
with, and never came up with something better). The user would see
something like this on linux/win32/solaris/etc.:
>./gdb
(gdb) info program
The program being debugged is not being run.
(gdb) info programs
Id Executable
* 1
(gdb)
(gdb) file ./gdb
Reading symbols from /home/pedro/gdb/sspaces/build/gdb/gdb...done.
(gdb) info programs
Id Executable
* 1 /home/pedro/gdb/sspaces/build/gdb/gdb
(gdb) start
Temporary breakpoint 1 at 0x453a37: file ../../src/gdb/gdb.c, line 28.
Starting program: /home/pedro/gdb/sspaces/build/gdb/gdb
[Thread debugging using libthread_db enabled]
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe378) at ../../src/gdb/gdb.c:28
28 memset (&args, 0, sizeof args);
(gdb) info programs
Id Executable
* 1 /home/pedro/gdb/sspaces/build/gdb/gdb
Bound inferiors: ID 1 (process 29358)
(gdb)
(gdb) clone-program
Added program 2.
1 program added.
(gdb) add-program
Added program 3
1 program added.
(gdb) add-program -exec ./testsuite/gdb.base/shreloc
Added program 4
Reading symbols from /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc...done.
1 program added.
(gdb) info programs
Id Executable
4 /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/shreloc
3
2 /home/pedro/gdb/sspaces/build/gdb/gdb
* 1 /home/pedro/gdb/sspaces/build/gdb/gdb
Bound inferiors: ID 1 (process 29358)
(gdb) info inferiors
Num Description Program ID Executable
* 1 process 29358 1 /home/pedro/gdb/sspaces/build/gdb/gdb
(gdb)
On DICOS-like targets (no main executable, all code from
shared libraries, all processes see the same set of symbols
at the same addresses), you'd see:
(gdb) info programs
Id Executable
1
(gdb) info inferiors
Num Description ProgramID Executable
5 capsule 131 1
4 capsule 65 1
3 capsule 31 1
2 capsule 20 1
* 1 capsule 11 1
(gdb)
Does this make some sense?
Thanks for your help! Very much appreciated.
--
Pedro Alves