From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10139 invoked by alias); 30 Sep 2002 21:39:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10127 invoked from network); 30 Sep 2002 21:39:16 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 30 Sep 2002 21:39:16 -0000 Received: from redhat.com (totem.toronto.redhat.com [172.16.14.242]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 69484800152 for ; Mon, 30 Sep 2002 17:39:16 -0400 (EDT) Message-ID: <3D98C484.4030500@redhat.com> Date: Mon, 30 Sep 2002 14:39:00 -0000 From: Fernando Nasser Organization: Red Hat , Inc. - Toronto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: RFC: ui_out type? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00511.txt.bz2 The old assembler code would print: 0x8048153 : push %ebp 0x8048154 : mov %esp,%ebp The new one prints: 0x08048153 : push %ebp 0x08048154 : mov %esp,%ebp Note the "+0" in 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