[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #15 from Nelson Chu --- (In reply to bzt from comment #13) > I've looked for another mirror (an unofficial github one), and compiling > that source produces an ld which can link font.o, *with* and *without* your > patch. I can also confirm that the order of the object files matter for > riscv64, > > riscv64-elf-ld font.o kernel.o -o kernel.elf > > Doesn't work, but > > riscv64-elf-ld kernel.o font.o -o kernel.elf > > does! I guess it's the additional logic with "only_data_sections" flag that > solves the problem. Yeah, Jim had solved this before, this behavior is what I expect. > So while "ld -b binary" still doesn't set the ELF header ABI flag to the > default ABI, if I use that (unofficial) latest binutils source that doesn't > matter. The fixed patch committed by Jim was in March/April 2019 before, so I suppose the recent official binutils should have the fix. > I still think that ld should set exactly the same ELF settings as > "as", that would be the proper solution (I understand it supposed to be "not > set", but there's an issue with "not set" and "soft-float" on riscv). I'm not sure if we need to do this, but we will discuss. It seems like we will only meet the problem that whether to generate the unknown/default abi flags when the input BFD are all "binaries". And if we set the default abi flags for those "binaries", then they can just be linked with the objects, which have the same abis. But shouldn't they be linked with any objects with any abi settings? Anyway, add a new "not set" abi flag should be the solution that same as most of targets, but we need to discuss this in the riscv psabi. > How to proceed from now on, is up to you. For me this ticket changed from > bug to nice-to-have because my regional mirror should update sooner or later > (I'm terribly sorry that my regional mirror is so up), so my project > will compile with it without hacks. You can close it if you like, or you can > try to use the same ELF options in "ld" as in "as" and come up with a > workaround for "not set". That's fine, and thanks for raising this issue again. For now we do have the configure --with-arch option for assembler that can build it with the default architecture as user want, but not for linker. I'm not sure if linker needs to know the default arch/abi setting, I think linker just need to set them according to the linked objects. The "binary" file with the soft-float abi flag is really confused, but it would be great if there is any solution that don't need to change the psabi... The solution in the PR-24389 is the one, just need to find a way to resolve the problem if the "binary" file is linked as the first object. Anyway, I think this topic may be worth discussing on the psabi, to make sure if we really need to give the default soft/float abi flags for the "binary" file. If the conclusion is yes, then Nick's proposal patch is good :) Thanks Nelson -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27218] Memory access violation in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27218 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-21 Assignee|unassigned at sourceware dot org |amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27221] Commit 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 introduces warnings while assembling the Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=27221 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-20 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- > Is this intentional? Yes, it was intentional. I may need to revisit that though, particularly since it isn't the user directly trying to emit line info for a non-code section here but -gdwarf-2. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27221] Commit 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 introduces warnings while assembling the Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=27221 Nathan Chancellor changed: What|Removed |Added CC||natechancellor at gmail dot com --- Comment #1 from Nathan Chancellor --- Created attachment 13141 --> https://sourceware.org/bugzilla/attachment.cgi?id=13141&action=edit arch/arm/mm/cache-v7.S, preprocessed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27221] Commit 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 introduces warnings while assembling the Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=27221 Nathan Chancellor changed: What|Removed |Added CC||amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27221] New: Commit 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 introduces warnings while assembling the Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=27221 Bug ID: 27221 Summary: Commit 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 introduces warnings while assembling the Linux kernel Product: binutils Version: 2.37 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: natechancellor at gmail dot com Target Milestone: --- When I build some Linux kernel targets with tip of tree binutils, I see a series of warnings like: Warning: dwarf line number information for ... ignored It looks like this was introduced by 058430b4a1ed7441dfc2e167bfdb9dc89ea9a209 according to my bisect. This is quite noisy in my builds as I see it with a variety of configurations and architectures. For example, with the attached cache-v7.s from the arch/arm directory: $ as-new -EL -mfloat-abi=soft -march=armv7-a -mfpu=vfp -mno-warn-deprecated -gdwarf-2 -o /dev/null cache-v7.s arch/arm/mm/cache-v7.S:84: Warning: dwarf line number information for .alt.smp.init ignored arch/arm/mm/cache-v7.S:100: Warning: dwarf line number information for .alt.smp.init ignored arch/arm/mm/cache-v7.S:105: Warning: dwarf line number information for .alt.smp.init ignored arch/arm/mm/cache-v7.S:200: Warning: dwarf line number information for .alt.smp.init ignored arch/arm/mm/cache-v7.S:218: Warning: dwarf line number information for .alt.smp.init ignored arch/arm/mm/cache-v7.S:310: Warning: dwarf line number information for .alt.smp.init ignored Is this intentional? If so, what is the fix? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27218] Memory access violation in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27218 --- Comment #3 from Sirus Shahini --- (In reply to Nick Clifton from comment #1) > (In reply to Sirus Shahini from comment #0) > > Please could you tell us the command line that you used when triggering this > crash ? > > Also, how were the binutils configured, and on what type of host machine ? > > Thanks. To reproduce just run: as zharf_crash000.as It crashes the last version in master branch. The test was done in an Ubuntu Linux with kernel 4.15. No specific configuration option passed to the build script. Just that the binary gets instrumented by our fuzzer for analysis and supervision. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27218] Memory access violation in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27218 --- Comment #2 from Sirus Shahini --- (In reply to Nick Clifton from comment #1) > (In reply to Sirus Shahini from comment #0) > > Please could you tell us the command line that you used when triggering this > crash ? > > Also, how were the binutils configured, and on what type of host machine ? > > Thanks. To reproduce just run: -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27218] Memory access violation in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27218 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Sirus Shahini from comment #0) Please could you tell us the command line that you used when triggering this crash ? Also, how were the binutils configured, and on what type of host machine ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27218] New: Memory access violation in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27218 Bug ID: 27218 Summary: Memory access violation in dwarf2dbg.c Product: binutils Version: 2.37 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sirus.shahini at gmail dot com Target Milestone: --- Created attachment 13139 --> https://sourceware.org/bugzilla/attachment.cgi?id=13139&action=edit Sample input Hello, Our fuzzer found a pointer corruption in 'dwarf2dbg.c'. This will result in an out of bound access to 'files' array. A crashing input attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #14 from bzt --- FYI, I've used this mirror: https://github.com/bminor/binutils-gdb/blob/master/bfd/elfnn-riscv.c Here _bfd_riscv_elf_merge_private_bfd_data starts at line 3781, so it's not exactly the same as yours either, but this is a version that works. Cheers, bzt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #13 from bzt --- Hi Nelson, I feel disturbance in the force... I'm using ftpmirror.gnu.org, which redirects to a regional mirror. The 2.35 source I can download from there definitely differs from yours, because according to your patch the function _bfd_riscv_elf_merge_private_bfd_data starts at line 3804, but in the downloaded source it's in line 3111 (so there must be quite a lot of difference, ~700 SLoC at least!) I've looked for another mirror (an unofficial github one), and compiling that source produces an ld which can link font.o, *with* and *without* your patch. I can also confirm that the order of the object files matter for riscv64, riscv64-elf-ld font.o kernel.o -o kernel.elf Doesn't work, but riscv64-elf-ld kernel.o font.o -o kernel.elf does! I guess it's the additional logic with "only_data_sections" flag that solves the problem. So while "ld -b binary" still doesn't set the ELF header ABI flag to the default ABI, if I use that (unofficial) latest binutils source that doesn't matter. I still think that ld should set exactly the same ELF settings as "as", that would be the proper solution (I understand it supposed to be "not set", but there's an issue with "not set" and "soft-float" on riscv). How to proceed from now on, is up to you. For me this ticket changed from bug to nice-to-have because my regional mirror should update sooner or later (I'm terribly sorry that my regional mirror is so up), so my project will compile with it without hacks. You can close it if you like, or you can try to use the same ELF options in "ld" as in "as" and come up with a workaround for "not set". Cheers, bzt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 Joel Sherrill changed: What|Removed |Added Target||aarch64-rtems aarch64-elf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] New: aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217
Bug ID: 27217
Summary: aarch64 as Internal error in md_apply_fix at
../gas/config/tc-aarch64.c:8330.
Product: binutils
Version: 2.35
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: joel.sherrill at oarcorp dot com
Target Milestone: ---
The following C code compiles and assembles cleanly on the other 17
architectures supported by RTEMS. But when compiled at -O2, -O1, and -Os on
aarch64, gcc produces assembly which gives an internal error. Examining the
generated assembly on arm and aarch64, enabling optimization results in the
.set statement being in the top part of the generated assembly versus the
bottom part. This pattern of .set placement is consistent across at least arm
and aarch64.
GCC's behavior related to the start and end of user assembly language comments
also varies based on optimization level. This isn't critical but odd. This type
of comment isn't generated for the arm.
===
extern char bar[];
char * foo(void)
{
return bar;
}
__asm__ (".set bar, 0");
===
$ /home/joel/rtems-work/tools/6/bin/aarch64-rtems6-gcc -c -O2 set.c
/tmp/ccyseDVm.s: Assembler messages:
/tmp/ccyseDVm.s: Internal error in md_apply_fix at
../../sourceware-mirror-binutils-gdb-8807d31/gas/config/tc-aarch64.c:8330.
Please report this bug.
This is the generated assembly so you do not need a full aarch64 toolchain.
===
.arch armv8-a
.file "set.c"
.text
// Start of user assembly
.set bar, 0
// End of user assembly
.align 2
.p2align 4,,11
.global foo
.type foo, %function
foo:
adrpx0, bar
add x0, x0, :lo12:bar
ret
.size foo, .-foo
.ident "GCC: (GNU) 10.2.1 20201030 (RTEMS 6, RSB
31dd1ab4424e59e48c60dfa587e805e908d13b02, Newlib 9517e5f)"
===
This is the assembly language at -O0 and it assembles successfully:
===
.arch armv8-a
.file "set.c"
.text
.align 2
.global foo
.type foo, %function
foo:
adrpx0, bar
add x0, x0, :lo12:bar
ret
.size foo, .-foo
// Start of user assembly
.set bar, 0
.ident "GCC: (GNU) 10.2.1 20201030 (RTEMS 6, RSB
31dd1ab4424e59e48c60dfa587e805e908d13b02, Newlib 9517e5f)"
===
I've confirmed this in the current master as well as an older version I had.
Based on reports from other RTEMS developers, this has been broken a while. I
personally confirmed it in these:
GNU assembler (GNU Binutils) 2.36.50.20210120
GNU assembler (GNU Binutils) 2.35.50.20201102
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/27210] ld: Don't suppress foo if foo@v1 is defined
https://sourceware.org/bugzilla/show_bug.cgi?id=27210 --- Comment #8 from H.J. Lu --- I opened an lld bug: https://bugs.llvm.org/show_bug.cgi?id=48820 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #12 from bzt --- > OK, so part of the problem is for the RISC-V, if the the ELF header flags are > zero then this means "uses soft float", rather than "no flags have been set". Yes, agreed. The other part being not been able to set the flag from command line for ld -b binary. > What should happen here ? If font.o is treated as having the default ABI > flags then it will not be possible to link it with c.o. I think that's okay and perfectly fine since you've used explicit "-mabi=lp64" on as command line, so it wasn't compiled for the default ABI. This can work if "ld -b binary" also accepts the same "-mabi=lp64" command line option. IMHO. > If none of them are riscv files (ie they are binary blobs) then the default > ABI flags should be set instead. Do you agree ? Well, I meant ABI flag set on object file creation, you seem to talk about object file load. If by "none of them are riscv files" you mean they don't have any text sections, only data section(s), then yes, can work. If I understand you correctly you're saying that when ld loads an object file without text segments, then it would assume default ABI for them? I guess the proper solution would be to only check the ABI flag if there's text section involved (only_data_sections == FALSE). > please could you try out the patch that I am about to upload and let me know > if it solves the problem for you. Of course, I'll try it and let you know the results. > This looks like a hack, but I don't know why currently... Yes, agreed very hackish. One thing that concerns me is that the order of the object files matter. But defendable, and if I can link C or "as" generated objects with binary objects then I'm fine with it! I'll let you know if your patch worked, keep tuned. Cheers, bzt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 --- Comment #1 from Andreas Schwab --- /* Parse the .sleb128 and .uleb128 pseudos. Only allow constant expressions, since these directives break relaxation when used with symbol deltas. */ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] New: as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Bug ID: 27215 Summary: as: Error: non-constant .uleb128 is not supported on riscv64 Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: mjw at fedoraproject dot org Target Milestone: --- The following test-case comes from dwz test-suite: $ cat repro.S .uleb128.Lexpr_end4 - .Lexpr_start3 .Lexpr_start3: .Lexpr_end4: $ ./gas/as-new repro.S repro.S: Assembler messages: repro.S:1: Error: non-constant .uleb128 is not supported $ ./gas/as-new --version GNU assembler (GNU Binutils) 2.36.50.20210120 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `riscv64-linux'. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27214] New: Outputting hex file with --verilog-data-width 4 uses incorrect offsets
https://sourceware.org/bugzilla/show_bug.cgi?id=27214 Bug ID: 27214 Summary: Outputting hex file with --verilog-data-width 4 uses incorrect offsets Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: shareef at jalloq dot co.uk Target Milestone: --- I'm using the gcc-arm-none-eabi-9-2020-q2-update version of objcopy and trying to output a hex file for Verilog simulation using $readmemh. It looks like the --verilog-data-width switch outputs the correct size data chunks but doesn't update the address offsets. If using the default options of: arm-none-eabi-objcopy -S source.o -O verilog source.hex I can load a byte array using $readmemh with no issue. If I specify the following: arm-none-eabi-objcopy -S source.o -O verilog --verilog-data-width 4 source.32.hex then I get 32-bit words but the indexes don't seem to be updated. When I try to run the simulator, the array index runs off the end of the array. Looking at the two output hex files, the first filled address is 0x0 which is fine. The next region seems to be set to the same value for both data widths which is obviously broken. source.32.hex: @265C ACDDFF7F 0100 source.hex @265C AC DD FF 7F 01 00 00 00 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200
Nelson Chu changed:
What|Removed |Added
CC||nelson.chu1990 at gmail dot com
--- Comment #11 from Nelson Chu ---
Hi Guys,
Jim had resolved the similar problem before, here is the details,
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
However, after the fixed, I think there is only one case that will cause the
"-b binary" cannot work expected - Link the binary file without any ABI setting
as the first linked object. The _bfd_riscv_elf_merge_private_bfd_data copy the
flags from input BFD to output BFD if elf_flags_init (obfd) is FALSE.
Therefore, we may copy the 0x0 flag from the binary file, if it is linked
first.
I suppose the Makefile in the Description should work, since the first linked
object is kernel.o rather than the binary font.o. However, the following
untested patch might work,
diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index b2ec6a2..578b29a 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -3804,13 +3804,6 @@ _bfd_riscv_elf_merge_private_bfd_data (bfd *ibfd, struct
bfd_link_info *info)
new_flags = elf_elfheader (ibfd)->e_flags;
old_flags = elf_elfheader (obfd)->e_flags;
- if (! elf_flags_init (obfd))
-{
- elf_flags_init (obfd) = TRUE;
- elf_elfheader (obfd)->e_flags = new_flags;
- return TRUE;
-}
-
/* Check to see if the input BFD actually contains any sections. If not,
its flags may not have been initialized either, but it cannot actually
cause any incompatibility. Do not short-circuit dynamic objects; their
@@ -3836,7 +3829,18 @@ _bfd_riscv_elf_merge_private_bfd_data (bfd *ibfd, struct
bfd_link_info *info)
}
if (null_input_bfd || only_data_sections)
- return TRUE;
+ {
+ if (! elf_flags_init (obfd))
+ elf_elfheader (obfd)->e_flags = new_flags;
+ return TRUE;
+ }
+}
+
+ if (! elf_flags_init (obfd))
+{
+ elf_flags_init (obfd) = TRUE;
+ elf_elfheader (obfd)->e_flags = new_flags;
+ return TRUE;
}
At the beginning, I move "if (! elf_flags_init (obfd))" behind the input BFD
checking, to avoid copying the flags from the binary file with 0x0 flags. But
the change causes the ld testcase "Link with zlib-gabi compressed debug output
1" fails for rv64gc-linux toolchain... Therefore, I still copy the 0x0 flags
to the output BFD, if it is linked as the first files. But without turning the
elf_flags_init (obfd) to TRUE. This looks like a hack, but I don't know why
currently...
Thanks
Nelson
--
You are receiving this mail because:
You are on the CC list for the bug.
