[Bug gas/25863] New: MVE: Issue with scalar vmul inside an it block
https://sourceware.org/bugzilla/show_bug.cgi?id=25863 Bug ID: 25863 Summary: MVE: Issue with scalar vmul inside an it block Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: avieira at gcc dot gnu.org Target Milestone: --- When parsing the following with -march=armv8.1-m.main+mve.fp, GAS currently wrongfully rejects it. .syntax unified .text it lt vmullt.f32 s0, s1, s2 In my original code I only tested this still worked for non-mve assembly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25863] MVE: Issue with scalar vmul inside an it block
https://sourceware.org/bugzilla/show_bug.cgi?id=25863 Andre Vieira changed: What|Removed |Added Assignee|unassigned at sourceware dot org |avieira at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25806] [ld] Search for input files relative to the current linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=25806 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=161719466ac9ea5f186514312f6bce842181804f commit 161719466ac9ea5f186514312f6bce842181804f Author: Fangrui Song Date: Wed Apr 22 16:20:02 2020 +0100 For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths. PR ld/25806 * ldlang.h (struct lang_input_statement_struct): Add extra_search_path. * ldlang.c (current_input_file): New. (ldirname): New. (new_afile): Add from_filename parameter. Set extra_search_path. (lang_add_input_file): Pass current_input_file to new_afile. (load_symbols): Set current_input_file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25806] [ld] Search for input files relative to the current linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=25806 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Nick Clifton --- Patch applied. Note - testsuite patch may follow. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target
https://sourceware.org/bugzilla/show_bug.cgi?id=25665 --- Comment #12 from Tamar Christina --- Hi rrorden, While looking through the source code I noticed that AArch64 already has flag to control how and where stub sections get placed. If you look at the documentation https://sourceware.org/binutils/docs/ld/ARM.html#ARM there's a flag called --stub-group-size=N which actually not only controls group sizes but also placements. There are two special values here: +1: The default which tells the linker to try to use heuristics to place the stubs. These heuristics will favor code-size hence the error you're seeing. The heuristic here is telling it to put all stubs together after all sections to minimize code-size impact. -1: This flips this heuristics to favor distance over size. What this will do is if possible keep all stubs together, but if not it will place them directly after the section which has the function that needs them. The downside here is that it may have to duplicate veneers, which is not unreasonable since the other one is out of range. It won't do the duplication if another usable veneer is in range. Now any other value for N will tell the linker that the veneers can service at most N bytes away from the input section with the + or - giving you the direction. So in our case, you just need to use the --stub-group-size=-1 heuristics and this will fix your case. Can you confirm and let me know? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target
https://sourceware.org/bugzilla/show_bug.cgi?id=25665 --- Comment #13 from rrorden at ptc dot com --- This sounds very promising. I will do some tests and report. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25866] New: bugs while compiling binutils using afl-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=25866
Bug ID: 25866
Summary: bugs while compiling binutils using afl-gcc
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: rfstudy2020 at gmail dot com
Target Milestone: ---
When I was following the online tutorial of AFL fuzzing binutils.
I git cloned the binutils software into a new directory and tried to compile it
with :
CC=afl-gcc ./configure
make
And I got bugs as follows:
```
afl-cc 2.52b by
In file included from ./../include/alloca-conf.h:1:0,
from sysdep.h:23,
from arparse.y:29:
./config.h:7:4: error: #error config.h must be #included before system headers
# error config.h must be #included before system headers
^
/usr/share/bison++/bison.cc: In function ‘yyparse’:
/usr/share/bison++/bison.cc:616:9: warning: this statement may fall through
[-Wimplicit-fallthrough=]
yyvsp = yyvs;
~~^~
/usr/share/bison++/bison.cc:377:23: note: here
#define YYLABEL(lb) } case lb: {
^
/usr/share/bison++/bison.cc:624:1: note: in expansion of macro ‘YYLABEL’
YYLABEL(yynewstate)
^~~
/usr/share/bison++/bison.cc:815:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
if (yyn == 0)
^
/usr/share/bison++/bison.cc:377:23: note: here
#define YYLABEL(lb) } case lb: {
^
/usr/share/bison++/bison.cc:819:1: note: in expansion of macro ‘YYLABEL’
YYLABEL(yyreduce)
^~~
/usr/share/bison++/bison.cc:981:11: warning: this statement may fall through
[-Wimplicit-fallthrough=]
yystate = *--yyssp;
^~
/usr/share/bison++/bison.cc:377:23: note: here
#define YYLABEL(lb) } case lb: {
^
/usr/share/bison++/bison.cc:997:1: note: in expansion of macro ‘YYLABEL’
YYLABEL(yyerrhandle)
^~~
Makefile:1505: recipe for target 'arparse.o' failed
make[4]: *** [arparse.o] Error 1
make[4]: Leaving directory '/home/runfeng/fuzzing/binutils-gdb/binutils'
Makefile:1135: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/runfeng/fuzzing/binutils-gdb/binutils'
Makefile:761: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/runfeng/fuzzing/binutils-gdb/binutils'
Makefile:3652: recipe for target 'all-binutils' failed
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory '/home/runfeng/fuzzing/binutils-gdb'
Makefile:853: recipe for target 'all' failed
make: *** [all] Error 2
```
I did not found anything useful online to address this bugs
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #14 from Wilco ---
So the bug is this in bfd/elfnn-aarch64.c (group_sections, #3609):
/* But wait, there's more! Input sections up to stub_group_size
bytes before the stub section can be handled by it too. */
if (!stubs_always_before_branch)
{
total = 0; --> BUG should be tail->size
while (prev != NULL
&& ((total += tail->output_offset - prev->output_offset)
< stub_group_size))
We're placing a stub section after tail, so we must reach from the start of the
previous section to the end of tail, not just to the start!
The Arm version of this function does this correctly - given it is much better
written, copying that is the best option.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target
https://sourceware.org/bugzilla/show_bug.cgi?id=25665 Tamar Christina changed: What|Removed |Added Assignee|tnfchris at sourceware dot org |wdijkstr at arm dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target
https://sourceware.org/bugzilla/show_bug.cgi?id=25665 Tamar Christina changed: What|Removed |Added CC|tnfchris at sourceware dot org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25866] bugs while compiling binutils using afl-gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=25866 Alan Modra changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- Sorry, but this sort of build error is not a bug. If you configured in the wrong directory (you should be running configure from the base of the binutils-gdb source tree), or are including other headers or otherwise doing something that is specific to your compile environment, then that is something you need to debug yourself. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861
--- Comment #4 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Max Filippov :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=30ce8e47fad9b057b6d7af9e1d43061126d34d20
commit 30ce8e47fad9b057b6d7af9e1d43061126d34d20
Author: Max Filippov
Date: Sun Apr 19 19:04:41 2020 -0700
xtensa: fix PR ld/25861
Introduce new relaxations XTENSA_PDIFF{8,16,32} for positive differences
(subtracted symbol precedes diminished symbol) and XTENSA_NDIFF{8,16,32}
for negative differences (subtracted symbol follows diminished symbol).
Don't generate XTENSA_DIFF relocations in the assembler, generate
XTENSA_PDIFF or XTENSA_NDIFF based on relative symbol position.
Handle XTENSA_DIFF in BFD for compatibility with old object files.
Handle XTENSA_PDIFF and XTENSA_NDIFF in BFD, treating difference value
as unsigned.
2020-04-22 Max Filippov
bfd/
* bfd-in2.h: Regenerated.
* elf32-xtensa.c (elf_howto_table): New entries for
R_XTENSA_PDIFF{8,16,32} and R_XTENSA_NDIFF{8,16,32}.
(elf_xtensa_reloc_type_lookup, elf_xtensa_do_reloc)
(relax_section): Add cases for R_XTENSA_PDIFF{8,16,32} and
R_XTENSA_NDIFF{8,16,32}.
* libbfd.h (bfd_reloc_code_real_names): Add names for
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32}.
* reloc.c: Add documentation for BFD_RELOC_XTENSA_PDIFF{8,16,32}
and BFD_RELOC_XTENSA_NDIFF{8,16,32}.
binutils/
* readelf.c (is_none_reloc): Recognize
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32}.
gas/
* config/tc-xtensa.c (md_apply_fix): Replace
BFD_RELOC_XTENSA_DIFF{8,16,32} generation with
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32} generation.
* testsuite/gas/xtensa/loc.d: Replace BFD_RELOC_XTENSA_DIFF16
with BFD_RELOC_XTENSA_PDIFF16 in the expected output.
include/
* elf/xtensa.h (elf_xtensa_reloc_type): New entries for
R_XTENSA_PDIFF{8,16,32} and R_XTENSA_NDIFF{8,16,32}.
ld/
* testsuite/ld-xtensa/relax-loc.d: New test definition.
* testsuite/ld-xtensa/relax-loc.s: New test source.
* testsuite/ld-xtensa/xtensa.exp (relax-loc): New test.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at sourceware dot org |jcmvbkbc at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from jcmvbkbc at gcc dot gnu.org --- Fixed in master. -- You are receiving this mail because: You are on the CC list for the bug.
