From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64048 invoked by alias); 20 Aug 2015 13:00:18 -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 64033 invoked by uid 89); 20 Aug 2015 13:00:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_05,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-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 20 Aug 2015 13:00:16 +0000 Received: by obbfr1 with SMTP id fr1so31016227obb.1 for ; Thu, 20 Aug 2015 06:00:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.144.194 with SMTP id so2mr2476855obb.51.1440075614974; Thu, 20 Aug 2015 06:00:14 -0700 (PDT) Received: by 10.76.10.196 with HTTP; Thu, 20 Aug 2015 06:00:14 -0700 (PDT) In-Reply-To: <20150820125344.GE4571@adacore.com> References: <1433628336-24058-1-git-send-email-jcmvbkbc@gmail.com> <20150820120909.GC4571@adacore.com> <20150820125344.GE4571@adacore.com> Date: Thu, 20 Aug 2015 13:00:00 -0000 Message-ID: Subject: Re: [PATCH] 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/msg00542.txt.bz2 On Thu, Aug 20, 2015 at 3:53 PM, Joel Brobecker wrote: >> The file include/xtensa-config.h is meant to be replaced by >> processor-specific version where XSHAL_ABI definition may be >> different. That's why I mention 'call0 configuration' in the >> description: when xtensa core is configured without >> windowed registers it will necessarily have call0 ABI. > > This is the type of property that is normally dynamically determined. > Is there a way to determine that info from the executable? That would > be the proper way of fixing this issue. I agree with that, but currently we can't distinguish executables with different call ABI. -- Thanks. -- Max