* Add fullname to breakpoint output
@ 2003-04-03 1:26 Bob Rossi
2003-04-04 16:59 ` Andrew Cagney
0 siblings, 1 reply; 10+ messages in thread
From: Bob Rossi @ 2003-04-03 1:26 UTC (permalink / raw)
To: gdb
Hi,
I wrote a patch that adds the fullname to breakpoint output.
(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
file="test.c",line="8",times="0"}
(gdb)
I would like confirmation on this before I go through the effort to
fix the testsuite.
What does everyone think? I think Andrew already seemed to think this
was a good idea.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-03 1:26 Add fullname to breakpoint output Bob Rossi
@ 2003-04-04 16:59 ` Andrew Cagney
0 siblings, 0 replies; 10+ messages in thread
From: Andrew Cagney @ 2003-04-04 16:59 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
> Hi,
>
> I wrote a patch that adds the fullname to breakpoint output.
>
> (gdb)
> -break-insert main
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
> addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
> file="test.c",line="8",times="0"}
> (gdb)
>
> I would like confirmation on this before I go through the effort to
> fix the testsuite.
The only alternative I can think of is:
file={fullname="/full/name", relname=".../...", dir="..."}
while astheticly pleasing, my past experience suggests that such strict
structuring eventually comes back and bites you - simple structures tend
to last longer.
Just post the code side of the change. Once resolved, the testsuite
should be `obvious'.
Andrew
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-14 4:14 ` Andrew Cagney
@ 2003-04-14 17:04 ` Jim Ingham
0 siblings, 0 replies; 10+ messages in thread
From: Jim Ingham @ 2003-04-14 17:04 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
To my mind, as long as you have "ui_out_text" sprinkled amongst the
result accumulating statements in "core" gdb, you have CLI code
embedded in the core gdb functionality. After all, the "text" output
was just a clever way to continue formatting stuff up for the CLI
without polluting the MI output. But having it there means command
output can't be changed without potentially messing up the CLI output -
the two are still intimately linked.
disasm.c has a bunch of ui_out_text calls.
Jim
On Sunday, April 13, 2003, at 09:14 PM, Andrew Cagney wrote:
>
>> Yes, this is a desirable goal. Have you thought about how to do this?
>
>> The best way I can think of is to have a new ui_out that builds up an
>> intermediate representation for results that is easy to access
>> randomly - making up real lists & dictionaries from the
>> ui_out_field_xxx and list & table stuff. Then we could banish
>> ui_out_text & friends to the CLI commands to take the whole result,
>> pull bits out in the order they expected, and annotate them with
>> text, newlines, etc, in order to make a nice display.
>> In practice, this will be gnarly to get right, but you could do it
>> incrementally by getting the intermediate rep. ui_out working, then
>> fix the CLI commands one by one by swapping in the new ui_out for
>> those commands you had fixed, and using the old CLI one for the
>> commands you hadn't gotten working...
>
> I don't know that anything that complicated is needed. disasm.c
> worked out pretty well.
>
> Andrew
>
>
>
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-05 17:59 ` Jim Ingham
@ 2003-04-14 4:14 ` Andrew Cagney
2003-04-14 17:04 ` Jim Ingham
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Cagney @ 2003-04-14 4:14 UTC (permalink / raw)
To: Jim Ingham; +Cc: gdb
> Yes, this is a desirable goal. Have you thought about how to do this?
> The best way I can think of is to have a new ui_out that builds up an intermediate representation for results that is easy to access randomly - making up real lists & dictionaries from the ui_out_field_xxx and list & table stuff. Then we could banish ui_out_text & friends to the CLI commands to take the whole result, pull bits out in the order they expected, and annotate them with text, newlines, etc, in order to make a nice display.
>
> In practice, this will be gnarly to get right, but you could do it incrementally by getting the intermediate rep. ui_out working, then fix the CLI commands one by one by swapping in the new ui_out for those commands you had fixed, and using the old CLI one for the commands you hadn't gotten working...
I don't know that anything that complicated is needed. disasm.c worked
out pretty well.
Andrew
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-05 17:28 ` Andrew Cagney
@ 2003-04-05 17:59 ` Jim Ingham
2003-04-14 4:14 ` Andrew Cagney
0 siblings, 1 reply; 10+ messages in thread
From: Jim Ingham @ 2003-04-05 17:59 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
On Saturday, April 5, 2003, at 09:28 AM, Andrew Cagney wrote:
>
>> In my view, the CLI should aim at minimalism, since a human being is
>> scanning it and too much information would be confusing. The MI is
>> intended to be scanned by a program, so we should feel free to cram
>> in whatever might be useful - within reason of course... For this
>> reason, when we found PB needed an extra bit of data which might not
>> be so useful to the CLI user, we would just add it to the MI only.
>> This is a little unsatisfying in implementation, since it means you
>> have
>> if (ui_out_is_mi_like (uiout))
>> {
>> }
>> scattered through non-interpreter specific code. But this is better
>> than cluttering up the CLI output for stuff that is more interesting
>> to a front-end...
>
> Just FYI, the current intermingling of CLI and MI code is short term -
> get something working. Medium to long term, the two need to be more
> cleanly separated. Related to this is separating more of the CLI from
> core GDB.
>
Yes, this is a desirable goal. Have you thought about how to do this?
The best way I can think of is to have a new ui_out that builds up an
intermediate representation for results that is easy to access randomly
- making up real lists & dictionaries from the ui_out_field_xxx and
list & table stuff. Then we could banish ui_out_text & friends to the
CLI commands to take the whole result, pull bits out in the order they
expected, and annotate them with text, newlines, etc, in order to make
a nice display.
In practice, this will be gnarly to get right, but you could do it
incrementally by getting the intermediate rep. ui_out working, then fix
the CLI commands one by one by swapping in the new ui_out for those
commands you had fixed, and using the old CLI one for the commands you
hadn't gotten working...
Idle Saturday speculation, maybe...
Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
jingham@apple.com
Developer Tools - gdb
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-04 22:19 ` Jim Ingham
@ 2003-04-05 17:28 ` Andrew Cagney
2003-04-05 17:59 ` Jim Ingham
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Cagney @ 2003-04-05 17:28 UTC (permalink / raw)
To: Jim Ingham; +Cc: gdb
> In my view, the CLI should aim at minimalism, since a human being is scanning it and too much information would be confusing. The MI is intended to be scanned by a program, so we should feel free to cram in whatever might be useful - within reason of course... For this reason, when we found PB needed an extra bit of data which might not be so useful to the CLI user, we would just add it to the MI only. This is a little unsatisfying in implementation, since it means you have
>
> if (ui_out_is_mi_like (uiout))
> {
>
> }
>
> scattered through non-interpreter specific code. But this is better than cluttering up the CLI output for stuff that is more interesting to a front-end...
Just FYI, the current intermingling of CLI and MI code is short term -
get something working. Medium to long term, the two need to be more
cleanly separated. Related to this is separating more of the CLI from
core GDB.
Andrew
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
2003-04-04 19:38 Nick Roberts
@ 2003-04-05 17:24 ` Andrew Cagney
0 siblings, 0 replies; 10+ messages in thread
From: Andrew Cagney @ 2003-04-05 17:24 UTC (permalink / raw)
To: Nick Roberts; +Cc: bob_rossi, gdb
>> > (gdb) -break-insert main
>> > ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
>> > addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
>> > file="test.c",line="8",times="0"}
>> > (gdb)
>
>
>> > I would like confirmation on this before I go through the effort to
>> > fix the testsuite.
>
>
> The CLI output doesn't give the absolute pathname:
Just FYI, this is an MI only change. The CLI will not be affected.
Andrew
> (gdb) break main
> Breakpoint 1 at 0x804856c: file mytest.c, line 36.
>
> so doesn't this add to the inconsistency? Since, as has been said before, on
> stopping CLI gives the absolute pathname:
>
> (gdb) run
> Starting program: /home/nick/mytest
>
> Breakpoint 1, main (argc=1, argv=0xbffff7d4) at mytest.c:36
> ^Z^Z/home/nick/mytest.c:36:466:beg:0x804856c
> (gdb)
>
> while MI gives the relative pathname:
>
> -exec-run
> ^running
> (gdb)
> *stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0804856c",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff7d4"}],file="mytest.c",line="36"}
>
> I don't think any of this would matter much if the search path for source
> files could be accessed by the front-end. Currently, however, unlike `path',
> `dir' resets rather than lists the current setting and the front-end can't
> (easily) access $cdir.
>
> Would it be a good idea to make the source path, $cdir, $cwd read-only
> convenience variables?
>
> Nick
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
[not found] <1049485092.22026.ezmlm@sources.redhat.com>
@ 2003-04-04 22:19 ` Jim Ingham
2003-04-05 17:28 ` Andrew Cagney
0 siblings, 1 reply; 10+ messages in thread
From: Jim Ingham @ 2003-04-04 22:19 UTC (permalink / raw)
To: gdb
> Hi,
>
> I wrote a patch that adds the fullname to breakpoint output.
>
> (gdb)
> -break-insert main
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
> addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
> file="test.c",line="8",times="0"}
> (gdb)
>
> I would like confirmation on this before I go through the effort to
> fix the testsuite. There is 85 test cases to fix. I would like to know
> that there is a general consensus that this patch would be an
> acceptable
> idea before I fix the testsuite.
>
> Thanks,
> Bob Rossi
>
>
Does it do this for both the CLI and the MI, or just the MI?
We found working on Project Builder that it was often more convenient
to add extra info to the MI output, but not to the CLI.
In my view, the CLI should aim at minimalism, since a human being is
scanning it and too much information would be confusing. The MI is
intended to be scanned by a program, so we should feel free to cram in
whatever might be useful - within reason of course... For this reason,
when we found PB needed an extra bit of data which might not be so
useful to the CLI user, we would just add it to the MI only. This is a
little unsatisfying in implementation, since it means you have
if (ui_out_is_mi_like (uiout))
{
}
scattered through non-interpreter specific code. But this is better
than cluttering up the CLI output for stuff that is more interesting to
a front-end...
Jim
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Add fullname to breakpoint output
@ 2003-04-04 19:38 Nick Roberts
2003-04-05 17:24 ` Andrew Cagney
0 siblings, 1 reply; 10+ messages in thread
From: Nick Roberts @ 2003-04-04 19:38 UTC (permalink / raw)
To: bob_rossi, ac131313; +Cc: gdb
> > Hi,
> > I wrote a patch that adds the fullname to breakpoint output.
> > (gdb) -break-insert main
> > ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
> > addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
> > file="test.c",line="8",times="0"}
> > (gdb)
> > I would like confirmation on this before I go through the effort to
> > fix the testsuite.
The CLI output doesn't give the absolute pathname:
(gdb) break main
Breakpoint 1 at 0x804856c: file mytest.c, line 36.
so doesn't this add to the inconsistency? Since, as has been said before, on
stopping CLI gives the absolute pathname:
(gdb) run
Starting program: /home/nick/mytest
Breakpoint 1, main (argc=1, argv=0xbffff7d4) at mytest.c:36
^Z^Z/home/nick/mytest.c:36:466:beg:0x804856c
(gdb)
while MI gives the relative pathname:
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0804856c",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff7d4"}],file="mytest.c",line="36"}
I don't think any of this would matter much if the search path for source
files could be accessed by the front-end. Currently, however, unlike `path',
`dir' resets rather than lists the current setting and the front-end can't
(easily) access $cdir.
Would it be a good idea to make the source path, $cdir, $cwd read-only
convenience variables?
Nick
^ permalink raw reply [flat|nested] 10+ messages in thread
* Add fullname to breakpoint output
@ 2003-04-04 1:03 Bob Rossi
0 siblings, 0 replies; 10+ messages in thread
From: Bob Rossi @ 2003-04-04 1:03 UTC (permalink / raw)
To: gdb
Hi,
I wrote a patch that adds the fullname to breakpoint output.
(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
addr="0x080483c3",func="main",fullname="/home/bob/cvs/src/gdb/test.c",
file="test.c",line="8",times="0"}
(gdb)
I would like confirmation on this before I go through the effort to
fix the testsuite. There is 85 test cases to fix. I would like to know
that there is a general consensus that this patch would be an acceptable
idea before I fix the testsuite.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-04-14 17:04 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-03 1:26 Add fullname to breakpoint output Bob Rossi
2003-04-04 16:59 ` Andrew Cagney
2003-04-04 1:03 Bob Rossi
2003-04-04 19:38 Nick Roberts
2003-04-05 17:24 ` Andrew Cagney
[not found] <1049485092.22026.ezmlm@sources.redhat.com>
2003-04-04 22:19 ` Jim Ingham
2003-04-05 17:28 ` Andrew Cagney
2003-04-05 17:59 ` Jim Ingham
2003-04-14 4:14 ` Andrew Cagney
2003-04-14 17:04 ` Jim Ingham
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).