From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 2B9D83858C33 for ; Fri, 13 Jan 2023 22:25:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B9D83858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE9D6FEC; Fri, 13 Jan 2023 14:25:55 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F05BF3F71A; Fri, 13 Jan 2023 14:25:12 -0800 (PST) Message-ID: Date: Fri, 13 Jan 2023 22:25:11 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature. Content-Language: en-GB To: Jakub Jelinek Cc: Srinath Parvathaneni , gcc Patches , Kyrylo Tkachov , Richard Sandiford References: <2b3432d1-587e-4c2e-4297-327ffbe6ad1d@arm.com> From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3492.9 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 13/01/2023 22:12, Jakub Jelinek wrote: > On Fri, Jan 13, 2023 at 09:58:26PM +0000, Richard Earnshaw (lists) wrote: >> > I'm afraid increasing number of DWARF registers is ABI incompatible change. >> > E.g. libgcc __frame_state_for function fills in: >> > typedef struct frame_state >> > { >> >    void *cfa; >> >    void *eh_ptr; >> >    long cfa_offset; >> >    long args_size; >> >    long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1]; >> >    unsigned short cfa_reg; >> >    unsigned short retaddr_column; >> >    char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1]; >> > } frame_state; >> > >> > structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to >> > __LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to >> > DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER. >> > So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange for >> > PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value. >> > >> >      Jakub >> > >> >> So where's the red flag that warns about this? >> >> I also note that Richard Sandiford made a similar type of change for AArch64 >> in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and nothing was said >> about that at the time. >> >> It seems incredibly fragile to me to have some ABI based off the number of >> machine registers. > > It is.  The new unwinder fortunately doesn't suffer from this (at least I > think it doesn't), but in older gccs the unwinder could be split across > different > objects, having e.g. parts of the unwinder in one shared library and another > part in another one, each built by different GCC version. > > Guess targets which weren't supported in GCC 2.x are ok, while > __frame_state_for is in libgcc, nothing calls it, so while such changes > change the ABI, nothing likely cares. > But for older targets it is a problem. > > And it is hard to catch this in the testsuite, one would either need to > hardcode the count for each target in the test, or test with mixing GCC 2.x > compiled code with current trunk. > > Before the introduction of libgcc_eh.a etc., parts of the unwinder was e.g. > exported from glibc. > See e.g. > https://gcc.gnu.org/legacy-ml/gcc-patches/2001-07/threads.html#00472 > > for some details. > >         Jakub > So: 1) GCC-2.* didn't support the EABI, which is all we support these days. 2) the Arm port updated FIRST_PSEUDO_REGISTER in 2019 in r10-4441 (16155ccf588a403c033ccd7743329671bcfb27d5) and I didn't see any fallout from that. 3) The Arm port uses the unwinding mechanism defined by the ABI, not the dwarf2 based tables. So I'm inclined to think this probably isn't going to be a problem in reality. R.