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

Re: Problems when building NT kernel drivers with GCC / LD

Hi Pali, Hello! Just for a record, I filled individual issues to bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=30004 https://sourceware.org/bugzilla/show_bug.cgi?id=30139 https://sourceware.org/bugzilla/show_bug.cgi?id=30140 https://sourceware.org/bugzilla/show_bug.cgi?id=30141

Re: Problems when building NT kernel drivers with GCC / LD

Hi Pali, Hello! I would like to remind this thread for gcc/binutils developers. Most of these issues are still present and cause problems for compiling native PE binary. If you have questions or you need any other information please let me know. Have bug reports been filed for the individual

Re: Error: attempt to get value of unresolved symbol `L0'

Hi Pali, Hi Richard, Having file name and line number would be also useful as it took me some time to figure out where is the issue... Right - I have tried a little harder and come up with a follow up patch. This is now checked in, and given an input file that looks like this: % cat t.s

Re: Error: attempt to get value of unresolved symbol `L0'

Hi Pali, Hi Richard, Interesting... Another test case which is working fine: kernoffs: .word 0x4 - (. - 0x0) This works because this expression can be converted into an instruction and a relocation in the object file: % as t.s -o t.o % objdump -dr t.o Disassembly of section

Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)

Hi Thomas, +/* Linker supports '-v' option. */ +#define LINK_SPEC "%{v}" ..., Tom rightfully asked: [...] I wonder, normally we don't pass -v to ld, and need -Wl,-v for that. So, on my quest for making things uniform/simple, I now wonder: should we also forward GCC '-v' to binutils

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: Counting static __cxa_atexit calls

Hi Florian, What would be the most ELF-flavored way to implement this? After the final link, I expect that the count (or counts, we need a separate counter for thread-local storage) would show up under a new dynamic tag in the dynamic segment. This is actually a very good fit because older

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

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():

Re: [committed] exec-stack warning for test which wants executable stacks

Hi Jeff, Just FYI - I am also looking at adding in another warning. This time for when the linker creates a PT_LOAD segment which has all of the RWX flags set. At the moment my testing seems to show that it only causes problems when a custom linker script is used that defines its own

Re: [committed] exec-stack warning for test which wants executable stacks

Hi Jeff, I used -z execstack rather than --no-warn-execstack as the former is recognized by older versions of ld, but the latter is a new option. Thanks for it. Unfortunately, I should have looked at the other failures that have popped up over the last week.  Essentially all the nested

Re: [CVE] zlib (< 1.2.12) memory corruption

Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. Right - I have now updated the binutils-gdb

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

Re: [CVE] zlib (< 1.2.12) memory corruption

Hi Luis, There is a CVE [1] for zlib < 1.2.12 (released march 27th). GCC currently uses zlib 1.2.11, and binutils-gdb imports the zlib directory from GCC. The recommendation is to get it updated to 1.2.12, which contains the proper fix [2]. I am all for updating the binutils-gdb copy of

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

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"

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

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.

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: Making *-netbsd-* to mean ELF not a.out for all CPUs

Hi John, But they did offer some tentative support for my second suggestion of changing the meaning of bare "netbsd" --- "netbsdaout" would still be available to unambiguously request a.out for anyone that wants it. I think that this would be OK for the binutils, providing that when

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

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

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 +++

Re: GCC: v850-elf

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

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

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 ">buffer[16]" potentially overlaps with the destination buffer "ctx->buffer", which

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

[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

Accessing fields in the global_options structure from out-of-sync plugins

Hi Guys, With the annobin plugin for gcc I have a problem accessing some of the fields in the global_options structure. Although the plugin can use the macros defined in options.h, this only works if the plugin is in sync with gcc. If the plugin was built for one version of gcc, but

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. >> *

[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,

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.

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

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