* Re: MI level command
[not found] <20040709012815.GA4464@white>
@ 2004-07-12 17:38 ` Alain Magloire
0 siblings, 0 replies; 11+ messages in thread
From: Alain Magloire @ 2004-07-12 17:38 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
>
> On Thu, Jul 08, 2004 at 07:33:17PM -0400, Alain Magloire wrote:
> > Yellow
> >
> >
> > Scenario: We want to know wich level of MI that we are currently working in.
> > This can allow to adjust what MI command to use and how to parse them.
> >
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> > The version of gdb
> > gdb --version
> > show different things in different distributions, sometimes it is a number based on date
> > etc ...
> >
> > So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> > be a good thing ?
>
> I like this idea a lot. I will need it when I start getting more work
> done on TGDB. However, there is another DRY problem. What functions act
> which way for which level?
>
Agreed, it is a problem, I do not have any solutions. For example
say thread-list-ids been crashing or misbehaved and the latest gdb fix the
problems ... For front-ends how to know this is fix ?
In theory the combination of version and the MI level should have done the trick.
> Basically, should every front end understand that
> -file-list-exec-source-files outputs just the files for level 1 but it
> also outputs the libraries the files belong to in level2?
>
> One solution could be, for every MI function, we could generate a unique
> key. For example, mi1-file-list-exec-source-files,
> mi2-file-list-exec-source-files, ...
> This key would tell the front end to use that particular parsing
> function when checking the output of -file-list-exec-source-files.
>
> Is this to wacky?
>
It sounds like a lot of maintainance.
How about for every release of gdb we bumb up a number ?
Say MI level could return {0,1,2,..} and MI gdb version could return something else.
So the unique key is for a release and all commands ... basically having taking the role of version.
So why is "version" so mangle in gdb ?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-08-24 22:04 ` Andrew Cagney
2004-08-24 23:54 ` Bob Rossi
@ 2004-08-25 13:23 ` Alain Magloire
1 sibling, 0 replies; 11+ messages in thread
From: Alain Magloire @ 2004-08-25 13:23 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Alain Magloire, gdb
>
> > Yellow
> >
> >
> > Scenario: We want to know wich level of MI that we are currently working in.
> > This can allow to adjust what MI command to use and how to parse them.
> >
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> > The version of gdb
> > gdb --version
> > show different things in different distributions, sometimes it is a number based on date
> > etc ...
> >
> > So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> > be a good thing ?
>
> This needs to be resolved.
>
> I think its become clear that clients are choosing to support multiple
> debugger releases rather than certifying against a single debugger and
> mi version. This is contrary to the expectation that the clients would
> tightly couple their front end to a specific GDB and MI version, and
> consequently, when starting GDB, specify a specific MI version.
>
Yes, some embedded platforms are still using old versions and for whatever
reasons and can not move the latest/greatest. Frontends still need to cope
with this and detecting the version of MI will allow them to adjust.
> Given this, we need to change the way versioning is handled.
>
> - we can't create a situtation where GDB is required to retain existing
> [broken] behavior indefinitly
>
> - we can certainly look for ways that let the client use both old and
> newer GDB's - the clients then get to decide how much backward
> incompatibility they wish to retain without imposing the burdon on GDB.
>
> To that end:
>
> -> we should probably implement significant command output (and more
> importantly input) changes by adding a new command. A missing new
> command is easy to detect, just run it with no options.
>
> -> minor output changes (new field for instance) do not need a new command
>
> -> MI version changes tied to significant changes
>
100% agreement, here 8-).
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-08-24 22:04 ` Andrew Cagney
@ 2004-08-24 23:54 ` Bob Rossi
2004-08-25 13:23 ` Alain Magloire
1 sibling, 0 replies; 11+ messages in thread
From: Bob Rossi @ 2004-08-24 23:54 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Alain Magloire, gdb
On Tue, Aug 24, 2004 at 06:03:25PM -0400, Andrew Cagney wrote:
> >Yellow
> >
> >
> >Scenario: We want to know wich level of MI that we are currently working
> >in.
> > This can allow to adjust what MI command to use and how to parse them.
> >
> >Problems: No such command in MI and no GDB variable that we can test via
> >-gdb-show.
> > The version of gdb
> > gdb --version
> > show different things in different distributions, sometimes it is a
> > number based on date
> > etc ...
> >
> >So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> >be a good thing ?
>
> This needs to be resolved.
>
> I think its become clear that clients are choosing to support multiple
> debugger releases rather than certifying against a single debugger and
> mi version. This is contrary to the expectation that the clients would
> tightly couple their front end to a specific GDB and MI version, and
> consequently, when starting GDB, specify a specific MI version.
>
> Given this, we need to change the way versioning is handled.
>
> - we can't create a situtation where GDB is required to retain existing
> [broken] behavior indefinitly
>
> - we can certainly look for ways that let the client use both old and
> newer GDB's - the clients then get to decide how much backward
> incompatibility they wish to retain without imposing the burdon on GDB.
>
> To that end:
>
> -> we should probably implement significant command output (and more
> importantly input) changes by adding a new command. A missing new
> command is easy to detect, just run it with no options.
>
> -> minor output changes (new field for instance) do not need a new command
>
> -> MI version changes tied to significant changes
Agreed, this would be a *great* step in the right direction. I propose
that for every mi command, we give the signature, so that the client
knows exactly what the command is capable of. Just saying that a command
is there is not good enough.
It's very similar to POSIX coming out with a standard that says, the
function named select and poll must be present and then a C programmer
trying to interface with that function.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-08 23:33 Alain Magloire
2004-07-09 20:49 ` Jason Molenda
@ 2004-08-24 22:04 ` Andrew Cagney
2004-08-24 23:54 ` Bob Rossi
2004-08-25 13:23 ` Alain Magloire
1 sibling, 2 replies; 11+ messages in thread
From: Andrew Cagney @ 2004-08-24 22:04 UTC (permalink / raw)
To: Alain Magloire; +Cc: gdb
> Yellow
>
>
> Scenario: We want to know wich level of MI that we are currently working in.
> This can allow to adjust what MI command to use and how to parse them.
>
> Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> The version of gdb
> gdb --version
> show different things in different distributions, sometimes it is a number based on date
> etc ...
>
> So would a patch implementing
>
> -gdb-mi-level
> ^done,level=1
>
> be a good thing ?
This needs to be resolved.
I think its become clear that clients are choosing to support multiple
debugger releases rather than certifying against a single debugger and
mi version. This is contrary to the expectation that the clients would
tightly couple their front end to a specific GDB and MI version, and
consequently, when starting GDB, specify a specific MI version.
Given this, we need to change the way versioning is handled.
- we can't create a situtation where GDB is required to retain existing
[broken] behavior indefinitly
- we can certainly look for ways that let the client use both old and
newer GDB's - the clients then get to decide how much backward
incompatibility they wish to retain without imposing the burdon on GDB.
To that end:
-> we should probably implement significant command output (and more
importantly input) changes by adding a new command. A missing new
command is easy to detect, just run it with no options.
-> minor output changes (new field for instance) do not need a new command
-> MI version changes tied to significant changes
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-11 22:49 Nick Roberts
@ 2004-07-12 21:14 ` Jason Molenda
0 siblings, 0 replies; 11+ messages in thread
From: Jason Molenda @ 2004-07-12 21:14 UTC (permalink / raw)
To: Nick Roberts; +Cc: alain, gdb
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Jul 11, 2004, at 3:18 PM, Nick Roberts wrote:
>> So anyway, Nick makes a similar change, but with the order of
>> arguments being
>> "SHOW-VALUE VAROBJ-HANDLE". Ouch. He also added the --no-values and
>> --all-values command line arguments at the same time.
>
> I think I *did* have the arguments the other way round initially and
> Andrew
> Cagney advised me to reverse them.
It's not really an important detail - my gripe is more with the general
way that MI commands take their arguments and how they're extended over
time to handle more behaviors. There's no way you could have known
that we did it differently in the Apple sources.
(and to merge the two, I changed our gdb to handle both argument
styles, with the obvious problem that varobjs can't be named "1"/"0"
'cause it's ambiguous.)
>> I much prefer the -data-disassemble command where each piece of
>> information is
>> passed with a separate command argument flag (except for its "mixed
>> mode"
>> boolean integer as the optional last argument on the line, sigh).
>
> This is one command I find awkward as it doesn't do what the CLI
> command
> "disassemble" does. I guess it shows that we all want different things
> out
> of the same interface.
Yeah, in our version we extended the -data-disassemble command to have
the CLI type behavior as well. e.g. provide a start address and
optionally the # of insns to disassemble, and -data-disassemble does
what you'd expect. i.e.
[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 3129 bytes --]
--- /Network/Servers/madrid/Volumes/huis/jmolenda/j/sware/gdb/src/gdb/mi/mi-cmd-disas.c Mon Sep 30 08:57:26 2002
+++ mi-cmd-disas.c Fri Feb 6 17:28:03 2004
@@ -35,8 +35,13 @@
START-ADDRESS: address to start the disassembly at.
END-ADDRESS: address to end the disassembly at.
- or:
+ Optionally, you can leave out END-ADDRESS, in which case it
+ will disassemble the function around START-ADDRESS. In this
+ case we will also accept the HOW_MANY argument to throttle
+ the disassembly display at that number of assembly lines.
+ or:
+
FILENAME: The name of the file where we want disassemble from.
LINE: The line around which we want to disassemble. It will
disassemble the function that contins that line.
@@ -51,8 +56,8 @@
enum mi_cmd_result
mi_cmd_disassemble (char *command, char **argv, int argc)
{
- enum mi_cmd_result retval;
- CORE_ADDR start;
+/* APPLE LOCAL: hack to work around bug in our find_line_pc() replacement func */
+ CORE_ADDR start = 0;
int mixed_source_and_assembly;
struct symtab *s;
@@ -125,15 +130,22 @@ mi_cmd_disassemble (char *command, char
/* Allow only filename + linenum (with how_many which is not
required) OR start_addr + and_addr */
+ /* APPLE LOCAL: Allow only the start addr, and interpret this to mean
+ the same thing as in the disassemble command - disassemble the function
+ around the -s address. */
+
if (!((line_seen && file_seen && num_seen && !start_seen && !end_seen)
|| (line_seen && file_seen && !num_seen && !start_seen && !end_seen)
- || (!line_seen && !file_seen && !num_seen && start_seen && end_seen)))
+ || (!line_seen && !file_seen && !num_seen && start_seen && end_seen)
+ || (!line_seen && !file_seen && start_seen && !end_seen)))
error
- ("mi_cmd_disassemble: Usage: ( [-f filename -l linenum [-n howmany]] | [-s startaddr -e endaddr]) [--] mixed_mode.");
+ ("mi_cmd_disassemble: Usage: ( [-f filename -l linenum [-n howmany]] | [-s startaddr -e endaddr] | "
+ "[-s startaddr [-n howmany]]) [--] mixed_mode.");
if (argc != 1)
error
- ("mi_cmd_disassemble: Usage: [-f filename -l linenum [-n howmany]] [-s startaddr -e endaddr] [--] mixed_mode.");
+ ("mi_cmd_disassemble: Usage: [-f filename -l linenum [-n howmany]] [-s startaddr -e endaddr] | "
+ "[-s startaddr [-n howmany]] [--] mixed_mode.");
mixed_source_and_assembly = atoi (argv[0]);
if ((mixed_source_and_assembly != 0) && (mixed_source_and_assembly != 1))
@@ -151,6 +163,13 @@ mi_cmd_disassemble (char *command, char
if (!find_line_pc (s, line_num, &start))
error ("mi_cmd_disassemble: Invalid line number");
if (find_pc_partial_function (start, NULL, &low, &high) == 0)
+ error ("mi_cmd_disassemble: No function contains specified address");
+ }
+ else if (start_seen && !end_seen)
+ {
+ /* APPLE LOCAL: See above, if only start address, disassemble
+ the function around the start address. */
+ if (find_pc_partial_function (low, NULL, &low, &high) == 0)
error ("mi_cmd_disassemble: No function contains specified address");
}
[-- Attachment #3: Type: text/plain, Size: 4 bytes --]
J
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-09 20:49 ` Jason Molenda
2004-07-10 17:18 ` Arnaud Charlet
@ 2004-07-12 17:51 ` Alain Magloire
1 sibling, 0 replies; 11+ messages in thread
From: Alain Magloire @ 2004-07-12 17:51 UTC (permalink / raw)
To: Jason Molenda; +Cc: gdb
>
>
> On Jul 8, 2004, at 4:33 PM, Alain Magloire wrote:
>
> > So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> > be a good thing ?
>
>
> It would probably help some, but I don't see it as solving the problem.
> The MI version # changes very rarely,
Well it already did ... 3 times level 0, 1, 2
> and individual MI commands can
> change quite a bit within a single MI version. On the good side, the
> changes to MI commands' output are mostly additional information that
> can be ignored if not recognized (and, hopefully, worked around if
> absent).
>
How about bug fixes and misbehaved like Bob Rossi was mentionning.
How are you recognize this in the front end ?
> My bigger concern is the way MI commands are invoked -- many of the
> commands are (IMHO) poorly written, either written as if a human was
> typing them in or using numeric constants positionally to indicate
> different behaviors. Sometimes the entropy is reversed, e.g. Nick
> Roberts' addition of the "--all-values", "--no-values", and
> "--simple-values" arguments to -stack-list-locals was a change in the
> right direction. But consider -var-list-children. Long ago at Apple
> we'd extended this command so that the arguments to -var-list-children
> was "VAROBJ-HANDLE SHOW-VALUE" where SHOW-VALUE was an integer with
> magical meanings, akin to what -stack-list-locals did (we had a '2'
> that did created varobj's and the like).
>
Yes, I agree, there are inconsistencies in the commands, some understand "--"
as as separator some others do not. Some understand ""(double quotes) as way
to group a phrase some other do not. Some understand the escape char slash (\)
some ... do not. Some commands insist when passing spaces part of the argument that
you use quotes ... well some other if you do will return an error etc ...
... Not that I'm complaining 8-)
> So anyway, Nick makes a similar change, but with the order of arguments
> being "SHOW-VALUE VAROBJ-HANDLE". Ouch. He also added the --no-values
> and --all-values command line arguments at the same time.
>
> I don't mean to rag on Nick of course, but this illustrates the limited
> extensibility of MI commands that work like this. And I certainly
> don't mean to imply that Apple hasn't made similar misjudgements in our
> own MI commands -- just yesterday I was looking at an MI command that
> takes a thread number, a source filename, and a line number (so the
> user can move the PC around in a function), and the command looks like
> "-thread-set-pc THREADNO SOURCE:LINE". And now is the time in our
> program when we parse.
>
> I much prefer the -data-disassemble command where each piece of
> information is passed with a separate command argument flag (except for
> its "mixed mode" boolean integer as the optional last argument on the
> line, sigh).
>
>
> Oh, I got a little off topic.
>
Not at all, you are bang on.
> BTW one convenient thing we have in the Apple gdb is a
> -mi-verify-command MI command, so the GUI can see if a given command is
> available or not. It's very helpful, and the implementation is a snap,
> of course.
>
See Bob Rossi's followup on this.
Technically with a correct "MI Level" and "GDB Version" a front-end should
be able to know what is available and what is not.
Still it could be a usefull tool in the front-ends in our quest to tame MI.
> enum mi_cmd_result
> mi_cmd_mi_verify_command (char *command, char **argv, int argc)
> {
> char *command_name = argv[0];
> struct mi_cmd *cmd;
>
> if (argc != 1)
> error ("mi_cmd_mi_verify_command: Usage: MI_COMMAND_NAME.");
>
> cmd = mi_lookup (command_name);
>
> ui_out_field_string (uiout, "name", command_name);
> if (cmd != NULL)
> {
> ui_out_field_string (uiout, "defined", "true");
> ui_out_field_string (uiout, "implemented",
> ((cmd->cli.cmd != NULL) ||
> (cmd->argv_func != NULL) ||
> (cmd->args_func != NULL)) ? "true" : "false");
> }
> else
> {
> ui_out_field_string (uiout, "defined", "false");
> }
>
> return MI_CMD_DONE;
> }
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
@ 2004-07-11 22:49 Nick Roberts
2004-07-12 21:14 ` Jason Molenda
0 siblings, 1 reply; 11+ messages in thread
From: Nick Roberts @ 2004-07-11 22:49 UTC (permalink / raw)
To: jmolenda; +Cc: alain, gdb
> > So would a patch implementing
> > -gdb-mi-level
> > ^done,level=1
> > be a good thing ?
> It would probably help some, but I don't see it as solving the problem. The MI
> version # changes very rarely, and individual MI commands can change quite a
> bit within a single MI version. On the good side, the changes to MI commands'
> output are mostly additional information that can be ignored if not recognized
> (and, hopefully, worked around if absent).
I agree. I don't have the resources to track different MI versions and hope
to make the transition from annotations to a stable MI.
> So anyway, Nick makes a similar change, but with the order of arguments being
> "SHOW-VALUE VAROBJ-HANDLE". Ouch. He also added the --no-values and
> --all-values command line arguments at the same time.
I think I *did* have the arguments the other way round initially and Andrew
Cagney advised me to reverse them. I may be wrong about that. In any case I
don't really care which order they are in but clearly there should be
consistency. Currently it seems to be a bit of a free for all but if Apple can
provide a more rigorous standard then I will be happy to try to follow it.
> I much prefer the -data-disassemble command where each piece of information is
> passed with a separate command argument flag (except for its "mixed mode"
> boolean integer as the optional last argument on the line, sigh).
This is one command I find awkward as it doesn't do what the CLI command
"disassemble" does. I guess it shows that we all want different things out
of the same interface.
Nick
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-10 17:18 ` Arnaud Charlet
@ 2004-07-10 22:51 ` Bob Rossi
0 siblings, 0 replies; 11+ messages in thread
From: Bob Rossi @ 2004-07-10 22:51 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Jason Molenda, Alain Magloire, gdb
On Sat, Jul 10, 2004 at 07:17:53PM +0200, Arnaud Charlet wrote:
> > BTW one convenient thing we have in the Apple gdb is a
> > -mi-verify-command MI command, so the GUI can see if a given command is
> > available or not. It's very helpful, and the implementation is a snap,
> > of course.
>
> Looks very useful indeed.
>
> Any reason not to incorporate this function in the FSF version ?
I still think functions like this are only partly useful. The real
problem is that as a front end writer, even if the function exists,
there is no way of figuring out the I/O of the function. In some case's,
it's probably not even useful to know that a function exists, especially
as functions change through each release.
Bob Rossi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-09 20:49 ` Jason Molenda
@ 2004-07-10 17:18 ` Arnaud Charlet
2004-07-10 22:51 ` Bob Rossi
2004-07-12 17:51 ` Alain Magloire
1 sibling, 1 reply; 11+ messages in thread
From: Arnaud Charlet @ 2004-07-10 17:18 UTC (permalink / raw)
To: Jason Molenda; +Cc: Alain Magloire, gdb
> BTW one convenient thing we have in the Apple gdb is a
> -mi-verify-command MI command, so the GUI can see if a given command is
> available or not. It's very helpful, and the implementation is a snap,
> of course.
Looks very useful indeed.
Any reason not to incorporate this function in the FSF version ?
Arno
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MI level command
2004-07-08 23:33 Alain Magloire
@ 2004-07-09 20:49 ` Jason Molenda
2004-07-10 17:18 ` Arnaud Charlet
2004-07-12 17:51 ` Alain Magloire
2004-08-24 22:04 ` Andrew Cagney
1 sibling, 2 replies; 11+ messages in thread
From: Jason Molenda @ 2004-07-09 20:49 UTC (permalink / raw)
To: Alain Magloire; +Cc: gdb
On Jul 8, 2004, at 4:33 PM, Alain Magloire wrote:
> So would a patch implementing
>
> -gdb-mi-level
> ^done,level=1
>
> be a good thing ?
It would probably help some, but I don't see it as solving the problem.
The MI version # changes very rarely, and individual MI commands can
change quite a bit within a single MI version. On the good side, the
changes to MI commands' output are mostly additional information that
can be ignored if not recognized (and, hopefully, worked around if
absent).
My bigger concern is the way MI commands are invoked -- many of the
commands are (IMHO) poorly written, either written as if a human was
typing them in or using numeric constants positionally to indicate
different behaviors. Sometimes the entropy is reversed, e.g. Nick
Roberts' addition of the "--all-values", "--no-values", and
"--simple-values" arguments to -stack-list-locals was a change in the
right direction. But consider -var-list-children. Long ago at Apple
we'd extended this command so that the arguments to -var-list-children
was "VAROBJ-HANDLE SHOW-VALUE" where SHOW-VALUE was an integer with
magical meanings, akin to what -stack-list-locals did (we had a '2'
that did created varobj's and the like).
So anyway, Nick makes a similar change, but with the order of arguments
being "SHOW-VALUE VAROBJ-HANDLE". Ouch. He also added the --no-values
and --all-values command line arguments at the same time.
I don't mean to rag on Nick of course, but this illustrates the limited
extensibility of MI commands that work like this. And I certainly
don't mean to imply that Apple hasn't made similar misjudgements in our
own MI commands -- just yesterday I was looking at an MI command that
takes a thread number, a source filename, and a line number (so the
user can move the PC around in a function), and the command looks like
"-thread-set-pc THREADNO SOURCE:LINE". And now is the time in our
program when we parse.
I much prefer the -data-disassemble command where each piece of
information is passed with a separate command argument flag (except for
its "mixed mode" boolean integer as the optional last argument on the
line, sigh).
Oh, I got a little off topic.
BTW one convenient thing we have in the Apple gdb is a
-mi-verify-command MI command, so the GUI can see if a given command is
available or not. It's very helpful, and the implementation is a snap,
of course.
enum mi_cmd_result
mi_cmd_mi_verify_command (char *command, char **argv, int argc)
{
char *command_name = argv[0];
struct mi_cmd *cmd;
if (argc != 1)
error ("mi_cmd_mi_verify_command: Usage: MI_COMMAND_NAME.");
cmd = mi_lookup (command_name);
ui_out_field_string (uiout, "name", command_name);
if (cmd != NULL)
{
ui_out_field_string (uiout, "defined", "true");
ui_out_field_string (uiout, "implemented",
((cmd->cli.cmd != NULL) ||
(cmd->argv_func != NULL) ||
(cmd->args_func != NULL)) ? "true" : "false");
}
else
{
ui_out_field_string (uiout, "defined", "false");
}
return MI_CMD_DONE;
}
^ permalink raw reply [flat|nested] 11+ messages in thread
* MI level command
@ 2004-07-08 23:33 Alain Magloire
2004-07-09 20:49 ` Jason Molenda
2004-08-24 22:04 ` Andrew Cagney
0 siblings, 2 replies; 11+ messages in thread
From: Alain Magloire @ 2004-07-08 23:33 UTC (permalink / raw)
To: gdb
Yellow
Scenario: We want to know wich level of MI that we are currently working in.
This can allow to adjust what MI command to use and how to parse them.
Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
The version of gdb
gdb --version
show different things in different distributions, sometimes it is a number based on date
etc ...
So would a patch implementing
-gdb-mi-level
^done,level=1
be a good thing ?
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-08-25 13:23 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20040709012815.GA4464@white>
2004-07-12 17:38 ` MI level command Alain Magloire
2004-07-11 22:49 Nick Roberts
2004-07-12 21:14 ` Jason Molenda
-- strict thread matches above, loose matches on Subject: below --
2004-07-08 23:33 Alain Magloire
2004-07-09 20:49 ` Jason Molenda
2004-07-10 17:18 ` Arnaud Charlet
2004-07-10 22:51 ` Bob Rossi
2004-07-12 17:51 ` Alain Magloire
2004-08-24 22:04 ` Andrew Cagney
2004-08-24 23:54 ` Bob Rossi
2004-08-25 13:23 ` Alain Magloire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).