This is the mail archive of the gdb@sources.redhat.com 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]

Re: RFC: ui_out type?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]