From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27396 invoked by alias); 30 Nov 2017 13:06:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27381 invoked by uid 89); 30 Nov 2017 13:06:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Nov 2017 13:06:56 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D8874A6E6 for ; Thu, 30 Nov 2017 13:06:55 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 552F660A98; Thu, 30 Nov 2017 13:06:53 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches Subject: Re: [PATCH v2] Make '{add-,}symbol-file' not care about the position of command line arguments References: <20171129214451.14257-1-sergiodj@redhat.com> <20171130042448.30882-1-sergiodj@redhat.com> <2fba79f1-e16e-38f2-bc0f-1c27da05e5c1@redhat.com> <87po807xhu.fsf@redhat.com> Date: Thu, 30 Nov 2017 13:06:00 -0000 In-Reply-To: (Pedro Alves's message of "Thu, 30 Nov 2017 12:48:55 +0000") Message-ID: <87h8tb9aqb.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00831.txt.bz2 On Thursday, November 30 2017, Pedro Alves wrote: >>> Does this push_back directly here mean that these >>> two commands end up with different semantics? >>> >>> (gdb) add-symbol-file FILE 0 -s .text 0x1000 >>> (gdb) add-symbol-file -s .text 0x1000 FILE 0 >> >> The arguments are printed in a different order, yes: >> >> (gdb) add-symbol-file -s .text 0x100 ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0 >> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at >> .text_addr = 0x100 >> .text_addr = 0x0 >> (y or n) n >> Not confirmed. >> (gdb) add-symbol-file ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0 -s .text 0x100 >> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at >> .text_addr = 0x0 >> .text_addr = 0x100 >> (y or n) n >> Not confirmed. >> >>> Not sure that's a good idea. >> >> I'll work on it and make sure they're always printed in the same way. > > TBC, the worry was not really about the printing (that's minor), > but what is the actual resulting .text address that the symbol file > it loaded at in the end. But sounds like the printing order can > be used as proxy for checking that. It's not as robust as > actually loading the symbols and then checking what happened > (with e.g., printing a symbol's address), but it's good > enough. Right, I got it. The way I made it now, the address provided as .text will always be the first to be set/printed, even if the user provides a "-s .text" later. This maintains compatibility with the current way of doing things. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/