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://sourceware.org/bugzilla/show_bug.cgi?id=29312#c1
I have redirected them to file a bug report with the gcc system, but in
the hopes of getting a fix in quickly I am also attaching a patch
here. It just does the obvious thing of adding a recursion counter
and limit to the function.
Cheers
Nick
diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
index 36afcfae278..d6daf23af27 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -1082,6 +1082,18 @@ demangle_path_maybe_open_generics (struct rust_demangler *rdm)
if (rdm->errored)
return open;
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+ ++ rdm->recursion;
+ if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+ {
+ /* FIXME: There ought to be a way to report
+ that the recursion limit has been reached. */
+ rdm->errored = 1;
+ goto end_of_func;
+ }
+}
+
if (eat (rdm, 'B'))
{
backref = parse_integer_62 (rdm);
@@ -1107,6 +1119,11 @@ demangle_path_maybe_open_generics (struct rust_demangler *rdm)
}
else
demangle_path (rdm, 0);
+
+ end_of_func:
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
+
return open;
}
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-demangle.c b/libiberty/rust-demangle.c
index 3b24d63892a..d601182ac50 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -126,7 +126,7 @@ parse_integer_62 (struct rust_demangler *rdm)
return 0;
x = 0;
- while (!eat (rdm, '_'))
+ while (!eat (rdm, '_') && !rdm->errored)
{
c = next (rdm);
x *= 62;
@@ -1148,6 +1148,15 @@ demangle_const (struct rust_demangler *rdm)
if (rdm->errored)
return;
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+ ++ rdm->recursion;
+ if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+ /* FIXME: There ought to be a way to report
+ that the recursion limit has been reached. */
+ goto fail_return;
+}
+
if (eat (rdm, 'B'))
{
backref = parse_integer_62 (rdm);
@@ -1158,7 +1167,7 @@ demangle_const (struct rust_demangler *rdm)
demangle_const (rdm);
rdm->next = old_next;
}
- return;
+ goto pass_return;
}
ty_tag = next (rdm);
@@ -1167,7 +1176,7 @@ demangle_const (struct rust_demangler *rdm)
/* Placeholder. */
case 'p':
PRINT ("_");
- return;
+ goto pass_return;
/* Unsigned integer types. */
case 'h':
@@ -1200,18 +1209,20 @@ demangle_const (struct rust_demangler *rdm)
break;
default:
- rdm->errored = 1;
- return;
+ goto fail_return;
}
- if (rdm->errored)
-return;
-
- if (rdm->verbose)
+ if (!rdm->errored && rdm->verbose)
{
PRINT (": ");
PRINT (basic_type (ty_tag));
}
+
+ fail_return:
+ rdm->errored = 1;
+ pass_return:
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
}
static void
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 is not used.
Tested with a patched version of the binutils sources on an
x86-pc-linux-gnu target.
Cheers
Nick
2022-01-26 Nick Clifton
* rust-demangle.c (struct rust_demangler): Add a recursion
counter.
(demangle_path): Increment/decrement the recursion counter upon
entry and exit. Fail if the counter exceeds a fixed limit.
(demangle_type): Likewise.
(rust_demangle_callback): Initialise the recursion counter,
disabling if requested by the option flags.
diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
index 18c760491bd..3b24d63892a 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -74,6 +74,12 @@ struct rust_demangler
/* Rust mangling version, with legacy mangling being -1. */
int version;
+ /* Recursion depth. */
+ unsigned int recursion;
+ /* Maximum number of times demangle_path may be called recursively. */
+#define RUST_MAX_RECURSION_COUNT 1024
+#define RUST_NO_RECURSION_LIMIT ((unsigned int) -1)
+
uint64_t bound_lifetime_depth;
};
@@ -671,6 +677,15 @@ demangle_path (struct rust_demangler *rdm, int in_value)
if (rdm->errored)
return;
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+ ++ rdm->recursion;
+ if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+ /* FIXME: There ought to be a way to report
+ that the recursion limit has been reached. */
+ goto fail_return;
+}
+
switch (tag = next (rdm))
{
case 'C':
@@ -688,10 +703,7 @@ demangle_path (struct rust_demangler *rdm, int in_value)
case 'N':
ns = next (rdm);
if (!ISLOWER (ns) && !ISUPPER (ns))
-{
- rdm->errored = 1;
- return;
-}
+ goto fail_return;
demangle_path (rdm, in_value);
@@ -776,9 +788,15 @@ demangle_path (struct rust_demangler *rdm, int in_value)
}
break;
default:
- rdm->errored = 1;
- return;
+ goto fail_return;
}
+ goto pass_return;
+
+ fail_return:
+ rdm->errored = 1;
+ pass_return:
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
}
static void
@@ -870,6 +888,19 @@ demangle_type (struct rust_demangler *rdm)
return;
}
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+ ++ rdm->recursion;
+ if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+ /* FIXME: There ought to be a way to report
+ that the recursion limit has been reached. */
+ {
+ rdm->errored = 1;
+ -- rdm->recursion;
+ return;
+ }
+}
+
switch (tag)
{
case 'R':
@@ -1030,6 +1061,9 @@ demangle_type (struct rust_demangler *rdm)
rdm->next--;
demangle_path (rdm, 0);
}
+
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
}
/* A trait in a trait object may have some "existential projections"
@@ -1320,6 +1354,7 @@ rust_demangle_callback (const char *mangled, int options,
rdm.skipping_printing = 0;
rdm.verbose = (options & DMGL_VERBOSE) != 0;
rdm.version = 0;
+ rdm.recursion = (options & DMGL_NO_RECURSE_LIMIT) ? RUST_NO_RECURSION_LIMIT
: 0;
rdm.bound_lifetime_depth = 0;
/* Rust symbols always start with _R (v0) or _ZN (legacy). */
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. Once the patch has been accepted there it can be backported to the gcc and gdb/binutils repositories... Cheers Nick
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/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
index 6fd8f6a4db0..df09b7b8fdd 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -74,6 +74,12 @@ struct rust_demangler
/* Rust mangling version, with legacy mangling being -1. */
int version;
+ /* Recursion depth. */
+ uint recursion;
+ /* Maximum number of times demangle_path may be called recursively. */
+#define RUST_MAX_RECURSION_COUNT 1024
+#define RUST_NO_RECURSION_LIMIT ((uint) -1)
+
uint64_t bound_lifetime_depth;
};
@@ -671,6 +677,15 @@ demangle_path (struct rust_demangler *rdm, int in_value)
if (rdm->errored)
return;
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+ ++ rdm->recursion;
+ if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+ /* FIXME: There ought to be a way to report
+ that the recursion limit has been reached. */
+ goto fail_return;
+}
+
switch (tag = next (rdm))
{
case 'C':
@@ -688,10 +703,7 @@ demangle_path (struct rust_demangler *rdm, int in_value)
case 'N':
ns = next (rdm);
if (!ISLOWER (ns) && !ISUPPER (ns))
-{
- rdm->errored = 1;
- return;
-}
+ goto fail_return;
demangle_path (rdm, in_value);
@@ -776,9 +788,15 @@ demangle_path (struct rust_demangler *rdm, int in_value)
}
break;
default:
- rdm->errored = 1;
- return;
+ goto fail_return;
}
+ goto pass_return;
+
+ fail_return:
+ rdm->errored = 1;
+ pass_return:
+ if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
}
static void
@@ -1317,6 +1338,7 @@ rust_demangle_callback (const char *mangled, int options,
rdm.skipping_printing = 0;
rdm.verbose = (options & DMGL_VERBOSE) != 0;
rdm.version = 0;
+ rdm.recursion = (options & DMGL_NO_RECURSE_LIMIT) ? RUST_NO_RECURSION_LIMIT : 0;
rdm.bound_lifetime_depth = 0;
/* Rust symbols always start with _R (v0) or _ZN (legacy). */
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/configure.ac @@ -1278,7 +1278,7 @@ else WINDMC_FOR_BUILD="\$(WINDMC)" fi -AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_CXX # We must set the default linker to the linker used by gcc for the correct
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 supported. (So moving to the latest Autoconf and Automake releases would supersede this change.) Makes sense. Is changing to autoconf 2.70 something that is planned for the near future ? I actually have a Fedora BZ open suggesting that the binutils be upgraded to use autoconf 2.71. I have put off doing this however as I am not an autoconf expert and I have no idea what the consequences might be. Cheers Nick
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 now
almost 20 years old (it was released in April 2004), updating the
requirement to a newer version does seem reasonable. On the other
hand 6.8 is quite new (it was released in March 2021), so a lot of
systems out there may not have it.
Thoughts ?
Cheers
Nick
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30703
[2] https://sourceware.org/pipermail/binutils/2023-February/125943.html
Suggested patch:
diff --git a/configure.ac b/configure.ac
index 01cfd017273..10bfef1c6c5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3678,10 +3678,10 @@ case " $build_configdirs " in
*" texinfo "*) MAKEINFO='$$r/$(BUILD_SUBDIR)/texinfo/makeinfo/makeinfo' ;;
*)
changequote(,)
-# For an installed makeinfo, we require it to be from texinfo 4.7 or
+# For an installed makeinfo, we require it to be from texinfo 6.8 or
# higher, else we use the "missing" dummy.
if ${MAKEINFO} --version \
- | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])'
>/dev/null 2>&1; then
+ | egrep 'texinfo[^0-9]*(6\.([8-9]|[1-9][0-9])|[7-9]|[1-9][0-9])'
>/dev/null 2>&1; then
:
else
MAKEINFO="$MISSING makeinfo"
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-register] So I would like to apply the patch below to fix this. Is this OK ? Cheers Nick include/ChangeLog 2020-06-25 Nick Clifton * libiberty.h (bsearch_r): Remove use of the register keyword from the prototype. diff --git a/include/libiberty.h b/include/libiberty.h index 0bb5b81d4a..591e9ac48d 100644 --- a/include/libiberty.h +++ b/include/libiberty.h @@ -643,9 +643,9 @@ extern int pwait (int, int *, int); /* Like bsearch, but takes and passes on an argument like qsort_r. */ -extern void *bsearch_r (register const void *, const void *, - size_t, register size_t, - register int (*)(const void *, const void *, void *), +extern void *bsearch_r (const void *, const void *, + size_t, size_t, + int (*)(const void *, const void *, void *), void *); #if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
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-register] So I would like to apply the patch below to fix this. Is this OK ? Cheers Nick include/ChangeLog 2020-06-25 Nick Clifton * libiberty.h (bsearch_r): Remove use of the register keyword from the prototype. diff --git a/include/libiberty.h b/include/libiberty.h index 0bb5b81d4a..591e9ac48d 100644 --- a/include/libiberty.h +++ b/include/libiberty.h @@ -643,9 +643,9 @@ extern int pwait (int, int *, int); /* Like bsearch, but takes and passes on an argument like qsort_r. */ -extern void *bsearch_r (register const void *, const void *, - size_t, register size_t, - register int (*)(const void *, const void *, void *), +extern void *bsearch_r (const void *, const void *, + size_t, size_t, + int (*)(const void *, const void *, void *), void *); #if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
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. Is this OK ?
>
> Yes please! This was copied straight from bsearch.c, so you probably
> want to change bsearch.c and bsearch_r.c as well (just in case clang
> ever finds itself needing to build bsearch_r out of libiberty).
OK, here is a revised patch. Ian - is this OK ?
Cheers
Nick
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.
* bsearch_r.c (bsearch_r): Likewise.
diff --git a/include/libiberty.h b/include/libiberty.h
index 0bb5b81d4ac..591e9ac48d4 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -643,9 +643,9 @@ extern int pwait (int, int *, int);
/* Like bsearch, but takes and passes on an argument like qsort_r. */
-extern void *bsearch_r (register const void *, const void *,
- size_t, register size_t,
- register int (*)(const void *, const void *, void *),
+extern void *bsearch_r (const void *, const void *,
+ size_t, size_t,
+ int (*)(const void *, const void *, void *),
void *);
#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
diff --git a/libiberty/bsearch.c b/libiberty/bsearch.c
index 35fad19977c..18158b9591b 100644
--- a/libiberty/bsearch.c
+++ b/libiberty/bsearch.c
@@ -69,13 +69,13 @@ is respectively less than, matching, or greater than the array member.
* look at item 3.
*/
void *
-bsearch (register const void *key, const void *base0,
- size_t nmemb, register size_t size,
- register int (*compar)(const void *, const void *))
+bsearch (const void *key, const void *base0,
+ size_t nmemb, size_t size,
+ int (*compar)(const void *, const void *))
{
- register const char *base = (const char *) base0;
- register int lim, cmp;
- register const void *p;
+ const char *base = (const char *) base0;
+ int lim, cmp;
+ const void *p;
for (lim = nmemb; lim != 0; lim >>= 1) {
p = base + (lim >> 1) * size;
diff --git a/libiberty/bsearch_r.c b/libiberty/bsearch_r.c
index 79ebae9b0be..2a2ca6f5e23 100644
--- a/libiberty/bsearch_r.c
+++ b/libiberty/bsearch_r.c
@@ -70,14 +70,14 @@ is respectively less than, matching, or greater than the array member.
* look at item 3.
*/
void *
-bsearch_r (register const void *key, const void *base0,
- size_t nmemb, register size_t size,
- register int (*compar)(const void *, const void *, void *),
+bsearch_r (const void *key, const void *base0,
+ size_t nmemb, size_t size,
+ int (*compar)(const void *, const void *, void *),
void *arg)
{
- register const char *base = (const char *) base0;
- register int lim, cmp;
- register const void *p;
+ const char *base = (const char *) base0;
+ int lim, cmp;
+ const void *p;
for (lim = nmemb; lim != 0; lim >>= 1) {
p = base + (lim >> 1) * size;
[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,
whereas in fact it is supposed to move CC bits into a general
register.
The patch disables the movsicc pattern, which means that some
optimizations can be missed, but it does also fix the following
tests:
> PASS: gcc.c-torture/execute/20040709-1.c -O2 execution test
> PASS: gcc.c-torture/execute/20040709-1.c -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> PASS: gcc.c-torture/execute/20040709-1.c -O3 -g execution test
> PASS: gcc.c-torture/execute/20040709-1.c -Os execution test
> PASS: gcc.c-torture/execute/20040709-1.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none execution test
> PASS: gcc.c-torture/execute/20040709-1.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects execution test
> PASS: gcc.c-torture/execute/20040709-2.c -O2 execution test
> PASS: gcc.c-torture/execute/20040709-2.c -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> PASS: gcc.c-torture/execute/20040709-2.c -O3 -g execution test
> PASS: gcc.c-torture/execute/20040709-2.c -Os execution test
> PASS: gcc.c-torture/execute/20040709-2.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none execution test
> PASS: gcc.c-torture/execute/20040709-2.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects execution test
> PASS: gcc.c-torture/execute/20040709-3.c -O2 execution test
> PASS: gcc.c-torture/execute/20040709-3.c -O3 -g execution test
> PASS: gcc.c-torture/execute/20040709-3.c -Os execution test
> PASS: gcc.c-torture/execute/20040709-3.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none execution test
> PASS: gcc.c-torture/execute/20040709-3.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects execution test
> PASS: gcc.dg/strcmpopt_2.c execution test
> PASS: gcc.dg/lto/pr67452 c_lto_pr67452_0.o-c_lto_pr67452_0.o link, -O2 -flto
> -fopenmp-simd
Cheers
Nick
gcc/ChangeLog
2020-06-25 Nick Clifton
* config/m32r/m32r.md (movsicc): Disable pattern.
diff --git a/gcc/config/m32r/m32r.md b/gcc/config/m32r/m32r.md
index 823342af1b4..6ecd9ce89ab 100644
--- a/gcc/config/m32r/m32r.md
+++ b/gcc/config/m32r/m32r.md
@@ -2162,6 +2162,12 @@
""
"
{
+ /* FIXME: This expansion is hold over from a failed conversion of this
+ port away from using cc0. It still relies upon the last comparison
+ being the one that is now tested. Disabled for now in order to
+ improve the generation of working code. */
+ FAIL;
+
if (! zero_and_one (operands [2], operands [3]))
FAIL;
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. >> * bsearch_r.c (bsearch_r): Likewise. > > Sure, this is fine. Committed. Cheers Nick
[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 about a redefinition. Cheers Nick gcc/ChangeLog 2021-03-09 Nick Clifton * config/rx/rx.h (DBX_DEBUGGING_INFO): Define. (DWARF"_DEBUGGING_INFO): Define. diff --git a/gcc/config/rx/rx.h b/gcc/config/rx/rx.h index 8e23e311c03..59e1f7cfa96 100644 --- a/gcc/config/rx/rx.h +++ b/gcc/config/rx/rx.h @@ -628,6 +628,8 @@ typedef unsigned int CUMULATIVE_ARGS; #undef PREFERRED_DEBUGGING_TYPE #define PREFERRED_DEBUGGING_TYPE (TARGET_AS100_SYNTAX \ ? DBX_DEBUG : DWARF2_DEBUG) +#define DBX_DEBUGGING_INFO 1 +#define DWARF2_DEBUGGING_INFO 1 #define INCOMING_FRAME_SP_OFFSET 4 #define ARG_POINTER_CFA_OFFSET(FNDECL) 4
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 39
bytes into a region of size between 32 and 71 [-Werror=format-overflow=]
2260 | sprintf (buff, "movhi hi(%s), r0, r6\n\tmovea lo(%s), r6, r6\n\tjmp
r6",
|
^~~~
2261 | name, name);
|
I could not reproduce these in my local environment, but I suspect that
you are using a more recent version of gcc than me. The fix looks obvious
however, so please could you try out the attached patch and let me know
if it resolves the problem ?
Cheers
Nick
diff --git a/gcc/config/v850/v850.c b/gcc/config/v850/v850.c
index 249cb400177..db3002a2cfb 100644
--- a/gcc/config/v850/v850.c
+++ b/gcc/config/v850/v850.c
@@ -2181,7 +2181,7 @@ construct_restore_jr (rtx op)
unsigned long int first;
unsigned long int last;
int i;
- static char buff [100]; /* XXX */
+ static char buff [256]; /* XXX */
if (count <= 2)
{
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 results
in undefined behavior for "memcpy".
libiberty/sha1.c:261: remediation: Use memmove instead of "memcpy".
# 259| sha1_process_block (ctx->buffer, 64, ctx);
# 260| left_over -= 64;
# 261|-> memcpy (ctx->buffer, &ctx->buffer[16], left_over);
# 262| }
# 263| ctx->buflen = left_over;
Looking at the source code I am not sure if the problem can actually
be triggered in reality, but there seems to be no harm in being
cautious, so I would like to ask for permission to apply the following
patch:
diff --git a/libiberty/sha1.c b/libiberty/sha1.c
index e3d7f86e351..7d15d48d11d 100644
--- a/libiberty/sha1.c
+++ b/libiberty/sha1.c
@@ -258,7 +258,7 @@ sha1_process_bytes (const void *buffer, size_t len, struct
sha1_ctx *ctx)
{
sha1_process_block (ctx->buffer, 64, ctx);
left_over -= 64;
- memcpy (ctx->buffer, &ctx->buffer[16], left_over);
+ memmove (ctx->buffer, &ctx->buffer[16], left_over);
}
ctx->buflen = left_over;
}
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 patch, your addition to the patch and a fix for
the
above problem.
Cheers
Nick
diff --git a/gcc/config/v850/v850.c b/gcc/config/v850/v850.c
index 249cb400177..e0e5005d865 100644
--- a/gcc/config/v850/v850.c
+++ b/gcc/config/v850/v850.c
@@ -2181,7 +2181,7 @@ construct_restore_jr (rtx op)
unsigned long int first;
unsigned long int last;
int i;
- static char buff [100]; /* XXX */
+ static char buff [256]; /* XXX */
if (count <= 2)
{
@@ -2286,7 +2286,7 @@ construct_save_jarl (rtx op)
unsigned long int first;
unsigned long int last;
int i;
- static char buff [100]; /* XXX */
+ static char buff [255]; /* XXX */
if (count <= (TARGET_LONG_CALLS ? 3 : 2))
{
diff --git a/gcc/config/v850/v850.h b/gcc/config/v850/v850.h
index 23dfdf67dff..386f9f59e0b 100644
--- a/gcc/config/v850/v850.h
+++ b/gcc/config/v850/v850.h
@@ -700,6 +700,7 @@ typedef enum
/* Use dwarf2 debugging info by default. */
#undef PREFERRED_DEBUGGING_TYPE
#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
+#define DWARF2_DEBUGGING_INFO 1
#define DWARF2_FRAME_INFO 1
#define DWARF2_UNWIND_INFO 0
Re: GCC: v850-elf
Hi JBG, These three let it build. One done. Thanks for your support! No worries. Patch pushed. Cheers Nick
