Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: ui_out type?
Date: Mon, 30 Sep 2002 14:59:00 -0000	[thread overview]
Message-ID: <20020930215934.GB27886@nevyn.them.org> (raw)
In-Reply-To: <3D98C484.4030500@redhat.com>

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


  reply	other threads:[~2002-09-30 21:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-30 14:39 Fernando Nasser
2002-09-30 14:59 ` Daniel Jacobowitz [this message]
     [not found] <1033503424.916.ezmlm@sources.redhat.com>
2002-10-01 13:39 ` Jim Ingham
2002-10-01 13:47   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020930215934.GB27886@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=fnasser@redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox