Re: RFC: ui_out type?

Re: RFC: ui_out type?

[Jim Ingham]

Daniel,

On Tuesday, October 1, 2002, at 01:17  PM, 
gdb-digest-help@sources.redhat.com wrote:

> (gdb) disas 'std::collate<char>::do_compare(char const*, char const*, 
> char const*, char const*) const'
> Unmatched single quote.
>
> [Er... that's not what I wanted to show.  Does anyone know why we're
> reporting an unmatched quote there?  "print" works but not "disas".]
>
>

"disassemble" doesn't use decode_line_1 to parse it's input.  It has 
its own simplified parser for arguments, which doesn't handle many of 
the more complex tricks decode_line_1 can handle...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: RFC: ui_out type?

[Daniel Jacobowitz]

On Tue, Oct 01, 2002 at 01:38:32PM -0700, Jim Ingham wrote:
> Daniel,
> 
> On Tuesday, October 1, 2002, at 01:17  PM, 
> gdb-digest-help@sources.redhat.com wrote:
> 
> >(gdb) disas 'std::collate<char>::do_compare(char const*, char const*, 
> >char const*, char const*) const'
> >Unmatched single quote.
> >
> >[Er... that's not what I wanted to show.  Does anyone know why we're
> >reporting an unmatched quote there?  "print" works but not "disas".]
> >
> >
> 
> "disassemble" doesn't use decode_line_1 to parse it's input.  It has 
> its own simplified parser for arguments, which doesn't handle many of 
> the more complex tricks decode_line_1 can handle...

Thanks.  I'll add a note about this to the command parsing hitlist I'm
building.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ui_out type?

[Daniel Jacobowitz]

On Mon, Sep 30, 2002 at 05:39:16PM -0400, Fernando Nasser wrote:
> The old assembler code would print:
> 
> 0x8048153 <foostatic>:  push   %ebp
> 0x8048154 <foostatic+1>:        mov    %esp,%ebp
> 
> The new one prints:
> 
> 0x08048153 <foostatic+0>:       push   %ebp
> 0x08048154 <foostatic+1>:       mov    %esp,%ebp
> 
> Note the "+0" in <foostatic+0>
> 
> This is because the output code is shared between the CLI and MI output and 
> the MI output version 1 is always expecting the "offset" keyword, even if 
> it is zero (based on the current MI tests).
> 
> Sometimes it is necessary to test if the uiout object is of a certain 
> class.  In this case I would like to test if it is of the "cli" type and do 
> not generate the offset when it is zero.  Some other types it will be 
> necessary to check if the object is of the "mi" type, because we will need 
> to test which version of the MI we are generating output for.
> 
> I have filled the gdb/774 asking for a function like that.
> 
> I am currently stuck with the disassembler unification because I either 
> break a CLI test by having the "+0" in there (looks ugly, also), or I break 
> some MI tests by not having the 'offset="0"' there.
> 
> Note: The MI output keywords are supposed to be optional, so not having an 
> offset keyword in the output would be fine (meaning that it is a zero 
> offset). But the current v1 tests, which have power of spec, currently look 
> for it explicitly.  We should remove this from the v2 tests for the cases 
> the offset is zero, I believe.

Well, in that case, may I suggest that we align CLI output based on
some "reasonable" length offset?  Four digits maybe?  The example you
paste above strikes me as horrifically ugly, because of the indentation
change.

I also wonder if there's a way we could shorten this format somewhat. 
As witness, this output, which I saw earlier today:

(gdb) disas 'std::collate<char>::do_compare(char const*, char const*, char const*, char const*) const' 
Unmatched single quote.

[Er... that's not what I wanted to show.  Does anyone know why we're
reporting an unmatched quote there?  "print" works but not "disas".]

(gdb) disas 0x4c4e8
Dump of assembler code for function
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateRs:
0x4c4e8
<_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateRs>:
lui     gp,0x8
0x4c4ec
<_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateRs+4>:
addiu   gp,gp,4056
0x4c4f0
<_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateRs+8>:
addu    gp,gp,t9
0x4c4f4
<_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES3_S3_RSt8ios_baseRSt12_Ios_IostateRs+12>:
addiu   sp,sp,-72

There, that's the dump I wanted.  First of all, I suspect we should be
demangling.  Second of all, we should really find a way to print less. 
Something like:

In function: std::num_get<char, std::istreambuf_iterator<char,
  std::char_traits<char> > >::get(std::istreambuf_iterator<char,
  std::char_traits<char> >, std::istreambuf_iterator<char,
  std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, short&)
  const
0x4c4e8 [+0]:	lui gp, 0x8
0x4c4ec [+4]:	addiu gp,gp,4056
0x4c4f0 [+8]:	addiu gp,gp,t9
0x4c4f4 [+12]:	addiu sp,sp,-72

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RFC: ui_out type?

[Fernando Nasser]

The old assembler code would print:

0x8048153 <foostatic>:  push   %ebp
0x8048154 <foostatic+1>:        mov    %esp,%ebp

The new one prints:

0x08048153 <foostatic+0>:       push   %ebp
0x08048154 <foostatic+1>:       mov    %esp,%ebp

Note the "+0" in <foostatic+0>

This is because the output code is shared between the CLI and MI output and the 
MI output version 1 is always expecting the "offset" keyword, even if it is zero 
(based on the current MI tests).

Sometimes it is necessary to test if the uiout object is of a certain class.  In 
this case I would like to test if it is of the "cli" type and do not generate 
the offset when it is zero.  Some other types it will be necessary to check if 
the object is of the "mi" type, because we will need to test which version of 
the MI we are generating output for.

I have filled the gdb/774 asking for a function like that.

I am currently stuck with the disassembler unification because I either break a 
CLI test by having the "+0" in there (looks ugly, also), or I break some MI 
tests by not having the 'offset="0"' there.

Note: The MI output keywords are supposed to be optional, so not having an 
offset keyword in the output would be fine (meaning that it is a zero offset). 
But the current v1 tests, which have power of spec, currently look for it 
explicitly.  We should remove this from the v2 tests for the cases the offset is 
zero, I believe.




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9