This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sunday 06 September 2009 04:14:08, Eli Zaretskii wrote: > > From: Pedro Alves <pedro@codesourcery.com> > > Date: Sat, 5 Sep 2009 22:15:32 +0100 > > > > > IOW, I don't understand why we need to group inferiors by sspaces. > > > > I don't see how to model vfork (in the shared region) (, or DICOS) > > with just that. To the extreme, if you load a shared library in > > a vfork child, the parent ends up with it loaded too. > > Sorry, I don't understand this problem. Could you elaborate, please? With the DICOS model, here's what we have currently (and it is what made more sense when we added multi-process support for this target, which was the first target that we added multi-process to). (gdb) tar extended-remote foo:9999 ... (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7de0a60 0x00007ffff7df6d44 Yes so1.so 0x00007ffff7bb56a0 0x00007ffff7bd1cf8 Yes so2.so 0x00007ffff79901b0 0x00007ffff799cf88 Yes so3.so 0x00007ffff7710eb0 0x00007ffff774f258 Yes so4.so ... (gdb) info inferiors No inferiors. Remember that with extended-remote when you connect, gdb is not attached to any inferior. But, in the DICOS case, even when you're not attached to any process, you already know that layout of the target memory, and it's list of shared libraries and symbols. Those are not an "inferior" property. That would not be true against a linux gdbserver, for example. It would be somewhat strange that there's already an inferior listed on DICOS. You want to be able to do this: (gdb) attach 123 Attached to process 123. (gdb) attach 124 Attached to process 124. (gdb) attach 125 Attached to process 125. That is, you don't specify which program the inferior is running, and gdb doesn't warn you that a running program is already being debugged when you do "attach". There's no (useless, at least currently) a pre step of "add-inferior" for each attach. However, when debugging against a conventional unix-like target, even if it support multi-process, you do want GDB to say: (gdb) start ... (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) Otherwise, it just gets too confusing. IMO, it's of important that the single-inferior case works like it always has been, as that's the use case most users will use and are used to. The way I had solved this was by decoupling "inferiors" from "(virtual) address space + its set of loaded symbols". > > Note that the current GDB model is that inferiors only exist > > after a "run", that is, inferior ~= process. Before "run", > > there's no inferior, "info inferiors" is empty, yet, you > > have a program loaded already. > > That's the underlying technicality. No, I was really talking about the user visible model. GDB has worked like that since ever, even before "info inferiors" was added. Plus, this way of thinking has now been migrated to MI and to frontends. Most importantly, to MI's "thread group" concept: (gdb) -exec-run =thread-group-created,id="829" =thread-created,id="1",group-id="829" > From user perspective, we could > certainly think that the inferior ``exists'' as soon as there's a > possibility to issue the `file' command without replacing the > already existing inferiors. That somewhat restricts us to the unix model. I know that other debuggers do that (I can think of Frysk and TotalView, for example), but, those can afford thinking the whole world is unix. > > We need multiple simultaneous such states. > > Which states? The state the new symbol-space object collects. That is, the "executable + shared libraries + symbols" + all that can exist without an inferior. OTOH, if this sounds confusing to you, it's almost certain it will sound confusing to most users too. I'm one of those that needs to try and get a feel for things, so, i've spent a bit reworking things around to implement that add-inferior model, and here's what we have now: >./gdb ./gdb (top-gdb) info inferiors Num Description Executable * 1 <null> /home/pedro/gdb/sspaces/build/gdb/gdb (top-gdb) info inferiors Num Description Executable * 1 process 1429 /home/pedro/gdb/sspaces/build/gdb/gdb (top-gdb) kill Kill the program being debugged? (y or n) y (top-gdb) info inferiors Num Description Executable * 1 <null> /home/pedro/gdb/sspaces/build/gdb/gdb (top-gdb) add-inferior Added inferior 2 1 inferiors added. (top-gdb) info inferiors Num Description Executable 2 <null> * 1 <null> /home/pedro/gdb/sspaces/build/gdb/gdb (top-gdb) inferior 2 [Switching to inferior 2 [process 0] (<noexec>)] (top-gdb) file /home/pedro/gdb/tests/threads Reading symbols from /home/pedro/gdb/tests/threads...done. (top-gdb) info inferiors Num Description Executable * 2 <null> /home/pedro/gdb/tests/threads 1 <null> /home/pedro/gdb/sspaces/build/gdb/gdb (top-gdb) start Temporary breakpoint 4 at 0x400640: file threads.c, line 35. Starting program: /home/pedro/gdb/tests/threads [Thread debugging using libthread_db enabled] Temporary breakpoint 4, main () at threads.c:35 35 long i = 0; (top-gdb) info inferiors Num Description Executable * 2 process 1526 /home/pedro/gdb/tests/threads 1 <null> /home/pedro/gdb/sspaces/build/gdb/gdb The symbol-spaces concept is still needed and is still there, but the user doesn't see them anymore. I've moved "info symbol-spaces" to "maintenanced info symbol-spaces". This is similar, yet different from what was in the multiprocess-20081120-branch. In that branch, you'd have proto-inferiors (inferiors with pid == 0, like that <null> above), but, when you issued a "run", that would still created yet another inferior. That turned out to be a bad idea. So, in this new version, an inferior ID is stable across a "run" or "attach". This probably makes things simpler for python scripting. I've tweaked things around so that MI's thread-groups are created at the same time as before, but obviously, MI needs to be extended to be able to support multi-exec + multi-inferiors properly. Now, I've tried to make DICOS fit into this, but since there's always an inferior, you'll see that useless (and probably confusing) inferior listed: (gdb) tar extended-remote foo:9999 ... (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7de0a60 0x00007ffff7df6d44 Yes so1.so 0x00007ffff7bb56a0 0x00007ffff7bd1cf8 Yes so2.so 0x00007ffff79901b0 0x00007ffff799cf88 Yes so3.so 0x00007ffff7710eb0 0x00007ffff774f258 Yes so4.so ... (gdb) info inferiors Num Description Executable * 1 <null> (gdb) attach 123 Attached to process 123. (gdb) info inferiors Num Description Executable 1 <null> * 2 Process 2323 It's a shame, and that was one of my main concerns (that we'd end up getting too stuck in the unix model of things) but I guess we can live with it somehow. Does this make more sense to you? What do others think? I'm CCing Mark and in case he has anything to say from the frontend/DICOS side of things (and in case he is around currently, which I know is probably not the case), and Vladimir in case he has something to say in the MI/frontend side of things. It would great have this settled before GDB 7.0, so that 7 0 doesn't start off with a half-baked multi-inferior model, different from 6.8's multi-forks, only to change it again shortly after the release... What do people think about that? I'm attaching the current patch gzipped. The changelogs and the docs need to be updated yet, though. I'll handle that next and repost appropriately if people think this is better. As before, no regressions on x86_64-unknown-linux-gnu native and gdbserver. -- Pedro Alves
Attachment:
multiexec_always_inferior.diff.gz
Description: GNU Zip compressed data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |