RFA: Another Rust demangler recursion limit

Hi Jeff, [I am sending this to your directly since you seem to be the only one reviewing these patches]. Hot on the heels of the fix for the recursion problem in demangle_const a binutils user has filed another PoC that exposes a problem in demangle_path_maybe_open_generics(): https://

Re: RFA: Another Rust demangler recursion limit

Hi Jeff, OK. Thanks. And yes, I wish someone else was looking at this stuff.  Rust isn't really on my radar right now... I have been toying with the idea of putting myself forward as a maintainer for the libiberty sources. I just wish that I had more free time... Cheers Nick

Fix another Rust demangling bugs (PR 105039)

Hi Guys, Attached is a proposed patch to fix another Rust demangling bug reported in PR 105039. I would like to say that this is the last time that we will see this problem for the Rust demangler, but I am not that naive... OK to apply ? Cheers Nickdiff --git a/libiberty/rust-deman

Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile

Hi Simon, Ping. Patch approved - please apply. I appreciate that modifying these top level files is a bit nerve wracking, but I think that you have done a good job in this case. :-) Cheers Nick

RFA: libiberty: Fix infinite recursion in rust demangler (PRs 98886 and 99935)

Hi Guys, I would like to propose the patch below to fix a couple of sources of infinite recursion in libiberty's rust demangling code. This patch is based upon the one submitted for PR 99935, but extended to cope with the case presented in PR 98886 and also fixed so that the "uint" type

Re: [PATCH] msp430: Mark unused attribute

Hi Jan-Benedict, gcc/ChangeLog: * config/msp430/msp430.cc (msp430_single_op_cost): Mark unused argument. Okay for HEAD? Patch approved - please apply. (I think that this patch would also count as an "obvious" fix, but thanks for asking anyway). Cheers Nick

Re: Commit: Update libiberty sources

Hi H.J. My patch is needed to build binutils with LTO. I submitted a patch for GCC: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html Very well. I have reappplied your patch to the mainline and 2.37 branch sources. Cheers Nick

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

Hi Nick, Ping? Oops. PR libctf/27482 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided Changes to libtool need to be posted to the libtool project: https://www.gnu.org/software/libtool/ They have mailing lists for bug reports and patch submissions. O

RFA: Libiberty: Fix stack exhaunstion demangling corrupt rust names

Hi Guys, Attached is a proposed patch to fix PR 99935 and 100968, both of which are stack exhaustion problems in libiberty's Rust demangler. The patch adds a recursion limit along the lines of the one already in place for the C++ demangler. OK to apply ? Cheers Nick diff --git a/li

RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

Hi Guys, Given that gcc, gdb and now binutils are all now requiring C99 as a minimum version of C, are there any objections to updating configure.ac to reflect this ? Cheers Nick diff --git a/configure.ac b/configure.ac index a721316d07b..59b4194fb24 100644 --- a/configure.ac +++ b/conf

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

Hi Joseph, This isn't an objection, since upgrading auto* for the toolchain can be complicated, but note that AC_PROG_CC_C99 is obsolete in Autoconf 2.70 Ah - in which case changing to an about-to-be-obsolete macro is probably a bad idea. and instead AC_PROG_CC enables C11 mode if support

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

Hi Guys, On 4/30/21 7:36 PM, Simon Marchi wrote: I think this fix is obvious enough, I encourage you to push it, OK - I have pushed the patch to the mainline branches of both the gcc and binutils-gfdb repositories. Cheers Nick

RFC: Top level configure: Require a minimum version 6.8 texinfo

Hi Guys, Currently the top level configure.ac file sets the minimum required version of texinfo to be 4.7. I would like to propose changing this to 6.8. The reason for the change is that the bfd documentation now needs at least version 6.8 in order to build[1][2]. Given that 4.7 is

RFA: Remove use of register keyword in libiberty.h

Hi Ian, Hi Nick, Comping the GOLD linker with Clang has started producing this error message: In file included from gold/archive.cc:29: include/libiberty.h:646:25: error: 'register' storage class specifier is deprecated and incompatible with C++17 [-Werror,-Wdeprecated-reg

RFA: Remove use of register keyword in libiberty.h

Hi Ian, Hi Nick, Compiling the GOLD linker with Clang has started producing this error message: In file included from gold/archive.cc:29: include/libiberty.h:646:25: error: 'register' storage class specifier is deprecated and incompatible with C++17 [-Werror,-Wdeprecated-r

Re: RFA: Remove use of register keyword in libiberty.h

Hi Nick, Hi Ian, >> In file included from gold/archive.cc:29: >> include/libiberty.h:646:25: error: 'register' storage class >> specifier is deprecated and incompatible with C++17 >> [-Werror,-Wdeprecated-register] >> >> So I would like to apply the patch below to fix this.

[COMMITTED} m32r: Disable movsicc pattern

Hi Guys, I am checking in the patch below to fix several failures in the GCC testsuite for the M32R target. The issue is the movsicc pattern which is a holdover from when the port from converted from using cc0. The pattern was written as if a previous instruction had set the CC bits, w

Re: RFA: Remove use of register keyword in libiberty.h

Hi Guys, >> include/ChangeLog >> 2020-06-25 Nick Clifton >> >> * libiberty.h (bsearch_r): Remove use of the register keyword from >> the prototype. >> >> libiberty/ChangeLog >> 2020-06-25 Nick Clifton >> >> * bsearch.c (bsearch): Remove use of register keyword. >> * bsear

[COMMITED]: rx.h: Define supported debugging types.

Hi Guys, I am applying the patch below to fix a problem building the rx port. The rx.h header file defines PREFERRED_DEBUGGING_TYPE but it was not defining the types of debugging it preferred. This results in the definition in defaults.h being triggered and the compiler complaining abou

Re: GCC: v850-elf

Hi Jan-Benedict, With my re-started testing efforts, I've got another one for you I guess (`./configure --target=v850-elf && make all-gcc`): ../.././gcc/config/v850/v850.c: In function ‘char* construct_restore_jr(rtx)’: ../.././gcc/config/v850/v850.c:2260:22: error: ‘%s’ directive writing up to

RFA: libiberty: silence static analyzer warning

Hi Ian, One of the static analyzers we use is throwing up an error report for one of the libiberty source files: Error: BUFFER_SIZE (CWE-474): libiberty/sha1.c:261: overlapping_buffer: The source buffer "&ctx->buffer[16]" potentially overlaps with the destination buffer "ctx->buffer", which

Re: GCC: v850-elf

Hi Jan-Benedict, However, next one is: ../.././gcc/defaults.h:938: error: "PREFERRED_DEBUGGING_TYPE" redefined [-Werror] 938 | #define PREFERRED_DEBUGGING_TYPE NO_DEBUG Ah - this is the same as the fix needed for the RX target. Please try the attached patch. It includes my original p

Re: GCC: v850-elf

Hi JBG, These three let it build. One done. Thanks for your support! No worries. Patch pushed. Cheers Nick