From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 907213857C52 for ; Thu, 26 Nov 2020 20:28:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 907213857C52 Received: by mail-wr1-x434.google.com with SMTP id 23so3442090wrc.8 for ; Thu, 26 Nov 2020 12:28:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8byEqUT1RtfwXRrKgnqhWBPy0XnnL5Tm3+J9umyGtbs=; b=sxym6rs2G2FvPi8WDJugrPVWtJ0H4QYjg0g3MhOcalFoL5biuuJUYMfdO89ZKTnEb7 mbdBOq07PAdBsD1nMqx1GC7Q0ZXrlTzVSHta4m2gIX9cSB58POzFN7/IJMKzeT4JA1s2 CqUR7pOfwSm1Ju6d76tWZrhoHypfh/f3j8VgrZ7YTK1SAp6PIg2hDVdJhIiIdJLP9siA IDMKYUfl+YAzkl2aPXuSPjOca/EN+RIbZPVjQNYSQViDRYbKhhNrRWdUjMnb6vTn+K75 fvL26PPZD4ojEvRmdJDo2b4s/m9WMk4VSV55sb3ydiahlA8pR6Y+x9PM7zbybt4a0dez 8kRw== X-Gm-Message-State: AOAM533LDVOaJ12R6EQA2fwK3QfX6dBlLtI/qCLMGaq+e9YZCAgUfPP+ im9EmMuZa4JYjAbWkTPRYiWtjm544IQ= X-Google-Smtp-Source: ABdhPJwBZ9JQy5uvBWvSNUtkn4F1XfRsRIgo0cxMs5QiWEUR1wnea9DW+7LQe58ihBoPgQEsB5MbdQ== X-Received: by 2002:adf:ed46:: with SMTP id u6mr5896919wro.287.1606422495178; Thu, 26 Nov 2020 12:28:15 -0800 (PST) Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.gmail.com with ESMTPSA id v189sm10727664wmg.14.2020.11.26.12.28.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Nov 2020 12:28:14 -0800 (PST) From: Iain Sandoe X-Google-Original-From: Iain Sandoe Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers. In-Reply-To: Date: Thu, 26 Nov 2020 20:28:13 +0000 Cc: Jakub Jelinek , Rainer Orth , Andrew Stubbs Content-Transfer-Encoding: 8bit Message-Id: <67EFBE24-057F-4BB2-A91A-D9C4A60F01A4@sandoe.co.uk> References: <0099CE62-D849-40BA-BCBD-1AD3882AA9AD@sandoe.co.uk> <20201126133052.GX3788@tucnak> To: GCC Patches X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 20:28:18 -0000 Hi folks, Rainer Orth wrote: >> On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: >>> which shows that the problem is detected in the depths of >>> libbacktrace's DWARF reader. There's something completely off in >>> places, like line numbers well beyond the end of dwarf.c. >>> >>> TBH, I don't really feel like diving into the innards of libbacktrace >>> and DWARF at this point to investigate. >> >> Perhaps try binutils readelf -wi or dwarflint etc. to find out where >> things >> go wrong, and then just look at the assembly and whether it matches what >> as >> made out of it? > > that was certainly easier than getting into libbacktrace. I've looked > for the smallest object linked into libgo that showed readelf -wi > differences. errors.o had > > No wonder things go astray from there… maybe this is enough to cover all bases without having to do any version or target checks. (untested) objdump is not available on quite a few Darwin versions with perfectly functional uleb128 - so I don’t want to punt on those for absence of it. We already check for otool elsewhere. thoughts? Iain ----- # Check if we have .[us]leb128, and support symbol arithmetic with it. # Older versions of GAS and some tools based on those, have a bugs handling # these directive, even when they appear to accept them. gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128, [elf,2,11,0],, [ .data .uleb128 L2 - L1 L1: .uleb128 1280 .sleb128 -1010 L2: .uleb128 0x8000000000000000 ], [[ if test "x$gcc_cv_objdump" != x; then if $gcc_cv_objdump --full-contents conftest.o 2>/dev/null \ | grep '04800a8e 78808080 80808080 808001' >/dev/null; then gcc_cv_as_leb128=yes fi elif test "x$gcc_cv_otool" != x; then if $gcc_cv_otool -d conftest.o 2>/dev/null \ | grep '04 80 0a 8e 78 80 80 80 80 80 80 80 80 80 01' >/dev/null; then gcc_cv_as_leb128=yes fi else # play safe, assume the assembler is broken. : fi ]], [AC_DEFINE(HAVE_AS_LEB128, 1, [Define if your assembler supports .sleb128 and .uleb128.])], [AC_DEFINE(HAVE_AS_LEB128, 0, [Define if your assembler supports .sleb128 and .uleb128.])])