From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31590 invoked by alias); 5 Sep 2009 18:41:21 -0000 Received: (qmail 31578 invoked by uid 22791); 5 Sep 2009 18:41:19 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Sep 2009 18:41:14 +0000 Received: (qmail 23292 invoked from network); 5 Sep 2009 18:41:12 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Sep 2009 18:41:12 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [v4 2/2] multi-executable support Date: Sat, 05 Sep 2009 18:41:00 -0000 User-Agent: KMail/1.9.10 References: <200909030349.38319.pedro@codesourcery.com> <200909030352.43203.pedro@codesourcery.com> <83pra7992c.fsf@gnu.org> In-Reply-To: <83pra7992c.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909051941.12181.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00129.txt.bz2 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 > > + =A0Id =A0 Main Program > > + =A02 =A0 =A0goodbye > > + =A0 =A0 =A0 =A0Bound inferiors: ID 1 (process 21561) > > +* 1 =A0 =A0hello > > +@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}. =A0On > > +some targets, it is possible that multiple inferiors are bound to the > > +same symbol space. >=20 > 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"? =A0 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.ba= se/shreloc)] (gdb) start ... Temporary breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.base/shr= eloc.c:14 14 fn_1 (extern_var_1); (gdb)=20 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/sspace= s/build/gdb/testsuite/gdb.base/shreloc1.sl 0x00007ffff79de490 0x00007ffff79de578 Yes /home/pedro/gdb/sspace= s/build/gdb/testsuite/gdb.base/shreloc2.sl .... (gdb) sspace 1 .... (gdb) info sharedlibrary .... 0x00007fa6c9196490 0x00007fa6c9196578 Yes /home/pedro/gdb/sspace= s/build/gdb/testsuite/gdb.base/shreloc1.sl 0x00007fa6c8f95490 0x00007fa6c8f95578 Yes /home/pedro/gdb/sspace= s/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/s= hreloc1.c, line 9. (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 3 breakpoint keep y 3.1 y 0x00007f3efb62352c in fn_1 at ../../../src/gdb/testsui= te/gdb.base/shreloc1.c:9 sspace 2 3.2 y 0x00007fa6c9196533 in fn_1 at ../../../src/gdb/testsui= te/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 =3D {int (int, char **)} 0x453a28
(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 =3D {int (int, char **)} 0x453a28
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/gd= b.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)=20=20=20=20 > I could easily=20 > 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/shr= eloc.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)=20=20=20=20=20 (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=3D1, argv=3D0x7fffffffe378) 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)=20=20=20 (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/s= hreloc...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)=20=20=20=20=20=20 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. --=20 Pedro Alves