From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108484 invoked by alias); 20 Aug 2015 13:44:25 -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 108468 invoked by uid 89); 20 Aug 2015 13:44:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f181.google.com Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 20 Aug 2015 13:44:24 +0000 Received: by obbfr1 with SMTP id fr1so32106980obb.1 for ; Thu, 20 Aug 2015 06:44:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.255.200 with SMTP id as8mr2744429obd.30.1440078262036; Thu, 20 Aug 2015 06:44:22 -0700 (PDT) Received: by 10.76.10.196 with HTTP; Thu, 20 Aug 2015 06:44:21 -0700 (PDT) In-Reply-To: <20150820131441.GG4571@adacore.com> References: <1440075160-13310-1-git-send-email-jcmvbkbc@gmail.com> <20150820130736.GF4571@adacore.com> <20150820131441.GG4571@adacore.com> Date: Thu, 20 Aug 2015 13:44:00 -0000 Message-ID: Subject: Re: [RFC] Re: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep From: Max Filippov To: Joel Brobecker Cc: gdb-patches@sourceware.org, Maxim Grigoriev , Woody LaRue , Marc Gauthier Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-08/txt/msg00546.txt.bz2 On Thu, Aug 20, 2015 at 4:14 PM, Joel Brobecker wrote: >> I think you missed or ignored one comment about the fact that >> the code I am seeing in current xtensa-tdep.h is not what your patch >> says. So it seems to me you are sending a patch that doesn't seem >> to be applying to master. >> >> I would also be beneficial to explore what I was trying to explain >> regarding the fact that determining the proper ABI should be done >> on the fly, rather than hardcoded. This is particularly true with >> the fact that changing the hardcoded values involves adapting >> the contents of a file, which is not user-friendly, and nearly >> impossible for anyone but a knowledgeable GDB contributor. > > You answered in the other email: > | I agree with that, but currently we can't distinguish executables with > | different call ABI. > > Odd; that means that the linker would not reject the link of > objects that use different calling conventions? Wow, better be > careful! Yes, but as long as the calling convention is fixed for the toolchain this is not a problem. > In any case, I think what should really be done, if it has to be > hard-set in the debugger, is use a configure command-line option. > Or use a GDB setting "set xtensa call-abi [...]". This only increases the number of moving parts: where previously only a set of files had to be replaced we'd now have to change a set of files plus give some configuration options. It isn't needed for our usecase: the particular build of gdb is meant to be used with matching build of the compiler, linker and the hardware. > In the meantime, I have no strong objection to this code going in > on the grounds that it doesn't really make things all that worse. > But given that this is going against what I would recommend, give it > another week so that other Maintainers have a chance to comment > as well if they disagree with letting this in. -- Thanks. -- Max