From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 86A40385840A for ; Tue, 12 Sep 2023 18:44:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86A40385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0369458.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 38CFLwG3006269; Tue, 12 Sep 2023 20:44:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:references:from:to:cc :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=UsUXIJrfZBIJa5ajZ9wbNb2YQPuliQBEqHUdJwthCmA=; b=mR 5N6ez0PDDpLEISGRNjchRC6mYDpywaHbt0DaS2V9e260X/xFR8NRp11Ml1IRQXbW 8EV4bfWYspywJZP3giU/GPR5okbLK9K+O6lJtMgnpZ150iDZGxZwcenrO/+qWyPD wRi/Kh1TmSaIStCwM2wEOi8Sr3qKi2QG17bNXO5sdV28bYS8nEV1KZJPc2ifRIpV BeFYLR1qDcwpmAVQMmbGU1tQHNu6FWwgo5da3YpBaGrOh1ca+f4DKEYf2IW1Tpuh ECDcee6QSbwwgWjZxarGVOxj52T4LF3WRwG42Y2qF88pJDwSI0MMIkcsSdit4/kI 8bkfmtxrmKdj/oklVfSw== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3t2g1huw6y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Sep 2023 20:44:27 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6C5FA100058; Tue, 12 Sep 2023 20:44:26 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 5C4E82487E9; Tue, 12 Sep 2023 20:44:26 +0200 (CEST) Received: from [10.252.31.15] (10.252.31.15) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 12 Sep 2023 20:44:25 +0200 Message-ID: <1453fd2c-5a2d-a6cd-4cbf-2daf45b26283@foss.st.com> Date: Tue, 12 Sep 2023 20:44:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] libctf: ctf_member_next needs to return (ssize_t)-1 on error References: <20230825165333.34510-1-torbjorn.svensson@foss.st.com> <54adb46a-aaf6-2dbf-9df1-f7fd857dac7d@foss.st.com> <87wmx2dw0j.fsf@esperi.org.uk> <7f7ea2fb-c690-b48e-bfa8-99ca89690ad7@foss.st.com> <878r9ba2sf.fsf@esperi.org.uk> Content-Language: en-US From: Torbjorn SVENSSON To: Nick Alcock CC: Alan Modra , Yvan ROUX , In-Reply-To: <878r9ba2sf.fsf@esperi.org.uk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.31.15] X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-12_18,2023-09-05_01,2023-05-22_02 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 2023-09-12 16:23, Nick Alcock wrote: > On 8 Sep 2023, Torbjorn SVENSSON told this: > >> On 2023-09-07 14:10, Nick Alcock wrote: >>> On 30 Aug 2023, Alan Modra via Binutils outgrape: >>> >>>> On Wed, Aug 30, 2023 at 10:34:05AM +0200, Torbjorn SVENSSON wrote: >>>>> @Alan, any additional comments on this updated patch (except the missing >>>>> semicolon that I mention below)? >>>> >>>> I'm leaving it to Nick Alcock to decide what to do here. >>> I agree that we should indeed be returning -1 from all functions that >>> return an int (it used to, but ctf_id_t has to be an unsigned long). But >>> I think it might be less disruptive to do so via a new >>> ctf_set_errno_int() which is just like ctf_set_errno but returns an int >>> rather than an unsigned long. That eliminates a lot of {}ery and makes >>> each individual hunk smaller. >> >> Ok, I can do that instead if that's considered the proper way. > > I think it might be a good bit neater and a good bit less work :) Ok, I'll send a revised patch in the next few days. >>> My concern is that it's really hard to validate all this -- can anyone >>> think of a trick that would emit *consistent* warnings if we called >>> return (ctf_set_errno()) from a function returning int? I mean this >>> returning-int thing is a change I made ages ago, and despite making it >>> *and* attempting to validate on 64-bit Windows I have clearly not got it >>> right because it's drifted right out of correctness again. >>> >>> (Similarly, does anyone have a build/target triplet on which this goes >>> wrong? because it's not going wrong on any of my mingw64 or cygwin tests >>> as far as I can tell.) >> >> I discovered the issue using the GCC12 package for arm-none-eabi that Arm released >> (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), but built using the x86_64-w64-mingw GCC compiler on Linux. > > I'm wondering what the configure options were for binutils itself -- > anything? was it a cross at all? (I'll admit this description has > confused me a bit: is this a cross from mingw64 to aarch64 or what?) Sorry for not being more clear on this point. This is the configure line used to reproduce the issue outside a full build of an arm-none-eabi toolchain. I'm sure that a few of the arguments to configure can be dropped without impact on the problem, but I leave that to the reader to decide. INSTALL=/tmp/pr30836-libctf-inifinit-loop ./configure \ --build=x86_64-linux-gnu \ --host=x86_64-w64-mingw32 \ --target=arm-none-eabi \ --prefix=$INSTALL \ --infodir=$INSTALL/share/doc/gcc-arm-none-eabi/info \ --mandir=$INSTALL/share/doc/gcc-arm-none-eabi/man \ --htmldir=$INSTALL/share/doc/gcc-arm-none-eabi/html \ --pdfdir=$INSTALL/share/doc/gcc-arm-none-eabi/pdf \ --disable-nls \ --disable-werror \ --disable-sim \ --disable-gdb \ --enable-interwork \ --enable-plugins \ --with-sysroot=$INSTALL/arm-none-eabi \ --with-pkgversion=foo make -j8 V=1 CFLAGS="-O0 -g" make install >> I've opened a ticket for the issue where I've attached 2 object files that you can use to reproduce the issue without needing to >> rebuild GCC + multlibs to verify the problem. >> https://sourceware.org/bugzilla/show_bug.cgi?id=30836 > > Thanks! I hope I won't need them, but they might well come in handy... Using the above built binutils (ld.exe in this case) with the pr41893-1.o object file is enough to trigger the loop. >>> I kinda wish we could rely on having C11 -- type-generic macros are made >>> for cases like this :( >> >> Looks like it would be a nice fix indeed, but is there anything else >> that could be done to improve the situation without needing to go to >> C11? > > I've been trying to think of something other than adding whatever the > build is you saw this on to my regular test matrix. You know both the code and the CTF format better than I do, so maybe you can take a look at the .ctf section in pr41893-1.o and see why it is wrongly handled. It might well be that the error that I stumbled on (not returning -1 on failure) is not the real problem... Maybe the real problem is something less obvious in the parsing of the object file itself?