Re: Add fullname to breakpoint output

Re: Add fullname to breakpoint output

[Nick Roberts]

> > 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

Re: Add fullname to breakpoint output

[Andrew Cagney]

>> > (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
> 

Re: Add fullname to breakpoint output

[Jim Ingham]

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

Re: Add fullname to breakpoint output

[Andrew Cagney]

> 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

Re: Add fullname to breakpoint output

[Jim Ingham]

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

Re: Add fullname to breakpoint output

[Andrew Cagney]

> 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

Re: Add fullname to breakpoint output

[Jim Ingham]

> 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

Re: Add fullname to breakpoint output

[Andrew Cagney]

> 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

Add fullname to breakpoint output

[Bob Rossi]

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

Add fullname to breakpoint output

[Bob Rossi]

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