This is the mail archive of the gdb@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 Monday 16 November 2009 17:51:36 Marc Khouzam wrote: > > > -----Original Message----- > > From: Vladimir Prus [mailto:vladimir@codesourcery.com] > > Sent: Monday, November 16, 2009 5:22 AM > > To: 'gdb@sources.redhat.com'; Marc Khouzam > > Subject: Re: [MI] Extending -list-thread-groups --available > > to show cores > > > > On Sunday 08 November 2009 18:04:31 you wrote: > > > > > > > > Current GDB has a MI command -list-thread-groups to nagivate > > > the hierarchy of the debugged thing. This command also the the > > > --available option that cause GDB to report the processes that > > > can be attached to, as opposed to processes currently being > > > debugged. > > ... > > > While those changes seem relatively minor and in line with > > previous MI developments, > > > I wanted to pass them here. If there are no objections, > > I'll work in implementation > > > during coming weeks. > > > > Here's the updated spec. Comments? > > > > Core awareness > > ============== > > > > This document specifies MI extensions to inform the client about cores on > > which threads are executed. > > > > While the mapping from thread to core is volatile for traditional Linux > > applications, it can be fixed for Linux application that specifically > > pin threads, and is often fixed for embedded systems, and for those cases, > > making frontend aware of the mapping would be nice. > > > > The proposed changes affect the 'thread groups' interface, and are as > > follows: > > > > 1. The output of the --list-thread-groups command will include a new > > field, 'cores'. For the 'process' thread group it will a list of all > > cores on which threads in that group are currently running. For leafs, > > that field should be a list with a single element. The new field will > > be output regardless of whether the --available option is specified. > > > > Example: > > > > -list-thread-groups --available > > ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}] > > Great. > > > 2. To cut down on the number of roundtrips, the --list-thread-groups without > > parameters may optionally recurse into the thread hierarchy. New option, > > '--recurse N' will be used to control that. Originally, N will be required > > to be 1. The --recurse option can be used independelty from the --available > > option. > > > > Example: > > > > -list-thread-groups --available --recurse 1 > > ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2], > > threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]}, > > {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}] > > Very nice and forward thinking. > > > Note that in case of --available, recursing into thread groups may not be > > supported on a given target. In that case, the 'threads' field will be > > skipped. > > The doc should indicate that a frontend should not assume the presence of "threads=" > even when using --recurse. Sure. > > [CONSIDER: Shall -list-target-features report if --available + recurse works?] > > Say a target does not support this, do you forsee a performance impact if the > frontend still uses --recurse in this case? If not, then a frontend could > figure out if this is supported by looking at the result of the command. I think > that would be enough. > > In fact, if there is a performance impact, a frontend could stop using "--recurse" > when it first noticed the missing "thread=" from the output. But in that case, > using -list-target-features would be more elegant. > > That being say, it won't hurt any FEs if -list-target-features did report this > anyway. (In Eclipse, we don't use -list-target-features yet because we've focused > on Linux targets, but I think we should improved the support of other targets by > using -list-target-features.) I don't think that there's any perfomance impact for getting --recurse when it's not supported. And on the other hand, there's some trickery involved in reporting --recurse support, specifically over a remote connection. I'm gonna skip this for now, unless a real need to test for this up-front will surface. > > > 3. It will be possible to pass several group ids to --list-thread-groups. In > > that case, the output will be identical to that of '-list-thread-groups' > > without parameters, except that thread groups that were not listed as > > parameters will not be output. > > For clarity, there should be a point 2.5 which says that the --available option > will now be allowed for --list-thread-groups with parameters. I like this > addition which will allow to get information about an individual process without > having to list all available processes. I've added this clarification to (3) > > As for the output format, you have convinced me. > However, I suggest the doc clearly indicates that when using the single-parameter > form of --list-thread-groups the output will not contain the "group=" field. > I think this could become an FAQ kind of FE problem :-) I've added a note to that effect in the spec. > > > Example: > > > > -list-thread-groups --available --recurse 1 17 18 > > ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2], > > threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]}, > > {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}] > > Above it says that "--recurse" is for -list-thread-groups without parameters. > I guess the example should be > -list-thread-groups --available 17 18 > Would using --recurse here cause an error, or be ignored? In fact, I did not meant to prohibit --available + --recurse + several groups. I've adjust the wording above. > > 4. The *stopped notification will include a new field 'core', giving the core > > number on which the breakpoint is hit. This field will only be present if > > possible. > > My favorite :-) Not mine, implementation-wize, but well ;-) Here's a new revision. - Volodya > > Good stuff! > > Thanks > > Marc >
Attachment:
core-mi.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |