[Bug binutils/26350] New: FAIL: Multibyte symbol names
https://sourceware.org/bugzilla/show_bug.cgi?id=26350
Bug ID: 26350
Summary: FAIL: Multibyte symbol names
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: danglin at gcc dot gnu.org
Target Milestone: ---
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/' <
/mnt/gnu/binutils/src/
gas/testsuite/gas/elf/syms.s > tmpdir/asm.s
Executing on host: sh -c {sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/'
< /mnt/gnu/binutils/src/gas/testsuite/gas/elf/syms.s > tmpdir/asm.s}
(timeout
= 300)
spawn sh -c sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/' <
/mnt/gnu/binutils/src/gas/testsuite/gas/elf/syms.s > tmpdir/asm.s
../as-new -o tmpdir/syms.o tmpdir/asm.s
Executing on host: sh -c {../as-new -o tmpdir/syms.o tmpdir/asm.s 2>&1}
/dev/null dump.tmp (timeout = 300)
spawn [open ...]
/mnt/gnu/binutils/objdir64/gas/testsuite/../../binutils/readelf -S -s -p
.strtab tmpdir/syms.o > tmpdir/dump.out
Executing on host: sh -c
{/mnt/gnu/binutils/objdir64/gas/testsuite/../../binutils/readelf -S -s -p
.strtab tmpdir/syms.o > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 300)
spawn [open ...]
extra regexps in /mnt/gnu/binutils/src/gas/testsuite/gas/elf/syms.d starting
with "^ \[..\] sy.*mbol$"
EOF from tmpdir/dump.out
FAIL: Multibyte symbol names
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26349] New: FAIL: binutils-all/pr25543
https://sourceware.org/bugzilla/show_bug.cgi?id=26349
Bug ID: 26349
Summary: FAIL: binutils-all/pr25543
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: danglin at gcc dot gnu.org
Target Milestone: ---
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/' <
/mnt/gnu/binutils/src/binutils/testsuite/binutils-all/pr25543.s > tmpdir/asm.s
Executing on host: sh -c {sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/'
< /mnt/gnu/binutils/src/binutils/testsuite/binutils-all/pr25543.s >
tmpdir/asm.s}(timeout = 300)
spawn sh -c sed -e 's/^[ ]*.comm \([^,]*\),\(.*\)/\1 .comm \2/' <
/mnt/gnu/binutils/src/binutils/testsuite/binutils-all/pr25543.s > tmpdir/asm.s
/mnt/gnu/binutils/objdir64/binutils/../gas/as-new -o tmpdir/pr25543.o
tmpdir/asm.s
Executing on host: sh -c {/mnt/gnu/binutils/objdir64/binutils/../gas/as-new
-o tmpdir/pr25543.o tmpdir/asm.s 2>&1} /dev/null dump.tmp (timeout = 300)
spawn [open ...]
/mnt/gnu/binutils/objdir64/binutils/readelf -p.data tmpdir/pr25543.o >
tmpdir/dump.out
Executing on host: sh -c {/mnt/gnu/binutils/objdir64/binutils/readelf -p.data
tmpdir/pr25543.o > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 300)
spawn [open ...]
regexp_diff match failure
regexp "^ \[ 0\] line1 : This is a line without a newline at the end$"
line " [tx] line1 : This is a line without a newline at the end"
regexp_diff match failure
regexp "^ \[34\] line2 : This is a line with a newline at the end\\n$"
line " [tx] line2 : This is a line with a newline at the end\n"
regexp_diff match failure
regexp "^ \[66\] line3 : This is a line with a \\n$"
line " [tx] line3 : This is a line with a \n"
regexp_diff match failure
regexp "^ \[9b\] line4 : This is a line with a \^Mcontrol character$"
line " [tx] line4 : This is a line with a ^Mcontrol character"
regexp_diff match failure
regexp "^ \[cd\] line6 : The previous line was empty\\n$"
line " [tx] line6 : The previous line was empty\n"
FAIL: binutils-all/pr25543
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26339] [aarch64] unknown architectural extensions
https://sourceware.org/bugzilla/show_bug.cgi?id=26339 --- Comment #5 from Nick Desaulniers --- (In reply to David Spickett from comment #4) > Is there existing > code that uses it with gas perhaps. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/tlbflush.h In the Linux kernel header that uses tlb-rmi. It's C, but the inline assembly is what's tripping us up. It's pretty well commented what the functions in the header are for. Specifically, it looks like the functions flush_tlb_all/flush_tlb_mm/flush_tlb_page_nosync/flush_tlb_kernel_range/__flush_tlb_kernel_pgtable try to use `tlbi ` vmalle1/vmalle1is/aside1is/vale1is/vaale1is/vaae1is respectively. For out of line assembly files using `tlbi`, see: - arch/arm64/mm/proc.S - arch/arm64/kernel/hibernate-asm.S - arch/arm64/kernel/head.S - arch/arm64/kernel/entry.S - arch/arm64/kvm/hyp/nvhe/hyp-init.S I can also see the use of the tlbi related macros using tlbi in inline asm in some of the virtualization code: - arch/arm64/kvm/hyp/nvhe/tlb.c - arch/arm64/kvm/hyp/vhe/tlb.c - arch/arm64/kernel/sys_compat.c Is the tlbi instruction what was added in ARMv8.4 (tlb-rmi), or only certain operands? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26348] New: Malloc size error in strip-new
https://sourceware.org/bugzilla/show_bug.cgi?id=26348 Bug ID: 26348 Summary: Malloc size error in strip-new Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: seviezhou at 163 dot com Target Milestone: --- Created attachment 12753 --> https://sourceware.org/bugzilla/attachment.cgi?id=12753=edit malloc-size-error-write_zeros-elf-5406 I found a malloc size error in strip-new, source line is elf.c:5406:9, here is the detail: ## System info Ubuntu x86_64, gcc (Ubuntu 5.5.0-12ubuntu1), binutils (2.36 8c4c18181ea382adf407df235c7991feb0647bab) ## Configure CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure ## Command line ./binutils/strip-new -s -g -S -d -w -x -X -v -o /dev/null ./malloc-size-error-write_zeros-elf-5406 ## AddressSanitizer output ``` ==37618==WARNING: AddressSanitizer failed to allocate 0x2fff770 bytes ==37618==AddressSanitizer's allocator is terminating the process instead of returning 0 ==37618==If you don't like this behavior set allocator_may_return_null=1 ==37618==AddressSanitizer CHECK failed: /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:225 "((0)) != (0)" (0x0, 0x0) #0 0x4e841f in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/asan/asan_rtl.cc:69 #1 0x505395 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79 #2 0x4ee246 in __sanitizer::ReportAllocatorCannotReturnNull() /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:225 #3 0x4ee283 in __sanitizer::ReturnNullOrDieOnFailure::OnBadRequest() /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:241 #4 0x41f356 in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/asan/asan_allocator.cc:856 #5 0x4def04 in malloc /home/seviezhou/llvm-6.0.0/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:89 #6 0x59167a in bfd_malloc /home/seviezhou/binutils/bfd/libbfd.c:275:9 #7 0x591980 in bfd_zmalloc /home/seviezhou/binutils/bfd/libbfd.c:326:15 #8 0x669bcf in write_zeros /home/seviezhou/binutils/bfd/elf.c:5406:9 #9 0x669bcf in assign_file_positions_for_load_sections /home/seviezhou/binutils/bfd/elf.c:5831 #10 0x63bcd5 in assign_file_positions_except_relocs /home/seviezhou/binutils/bfd/elf.c:6388:12 #11 0x63bcd5 in _bfd_elf_compute_section_file_positions /home/seviezhou/binutils/bfd/elf.c:4336 #12 0x658cd6 in _bfd_elf_set_section_contents /home/seviezhou/binutils/bfd/elf.c:9276:12 #13 0x59fd29 in bfd_set_section_contents /home/seviezhou/binutils/bfd/section.c:1520:7 #14 0x528fc8 in copy_section /home/seviezhou/binutils/binutils/objcopy.c:4430:12 #15 0x59f6dc in bfd_map_over_sections /home/seviezhou/binutils/bfd/section.c:1379:5 #16 0x525bb5 in copy_object /home/seviezhou/binutils/binutils/objcopy.c:3266:3 #17 0x51eeea in copy_file /home/seviezhou/binutils/binutils/objcopy.c:3831:13 #18 0x5177d9 in strip_main /home/seviezhou/binutils/binutils/objcopy.c:4818:7 #19 0x5177d9 in main /home/seviezhou/binutils/binutils/objcopy.c:6016 #20 0x7f9cfcd9f83f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291 #21 0x41ad18 in _start (/home/seviezhou/experiment-5/AlphaFuzz-strip/test/strip-new+0x41ad18) ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25708
--- Comment #11 from H.J. Lu ---
(In reply to Michael Matz from comment #10)
> (In reply to H.J. Lu from comment #9)
> > >
> > > Is it really a good idea to change the output format of basic tools that
> > > might be
> > > used in machine processing context? (And I note there doesn't seem to be
> > > an
> > > cmdline option to get the old behaviour back, so fixing the problem now
> > > entails
> > > further massaging of nm output to cut off /@.*/ )
> >
> > Is this PR 26302? A patch is at
>
> No. perf does the moral equivalent of:
>
> % ( echo "{"; nm -D input.so | awk '{print $1";"}'; echo "}" ) > thelist
> % ld ... --dynamic-list=thelist
>
Please a new bug report with a small testcase.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25708
--- Comment #10 from Michael Matz ---
(In reply to H.J. Lu from comment #9)
> >
> > Is it really a good idea to change the output format of basic tools that
> > might be
> > used in machine processing context? (And I note there doesn't seem to be an
> > cmdline option to get the old behaviour back, so fixing the problem now
> > entails
> > further massaging of nm output to cut off /@.*/ )
>
> Is this PR 26302? A patch is at
No. perf does the moral equivalent of:
% ( echo "{"; nm -D input.so | awk '{print $1";"}'; echo "}" ) > thelist
% ld ... --dynamic-list=thelist
Of course 'thelist' now contains @ characters, because nm -D shows symversions,
and that's what ld is complaining about:
thelist:2: ignoring invalid character `@' in script
thelist:2: syntax error in dynamic list
collect2: error: ld returned 1 exit status
The build system of simply isn't prepared to deal with these symversions.
So one of several things need to happen:
a) nm -D doesn't print symversions, unless explicitely requested
b) nm -D continues to print them, but with an option to disable them
c) perf Makefile is changed to filter out any /@.*/ in the nm output
I'm not sure how widespread such usage of nm is, and hence how often fix (c)
would have to be applied in the wild. Fixing such packages would at least
be easier if nm had an option to disable printing them (i.e. (b)). But maybe
it's best to not change traditional behaviour of nm at all, i.e. change (a),
and revert to not printing symversions by default.
I don't know what's best.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/26347] New: Partial initialization of std::cout on linkage with `-static-libstdc++` and other dynamic library
https://sourceware.org/bugzilla/show_bug.cgi?id=26347
Bug ID: 26347
Summary: Partial initialization of std::cout on linkage with
`-static-libstdc++` and other dynamic library
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: demansong at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Dynamic library which I link with my application also incudes but it
wasn't linked with static lib stdc++.
The problem goes away when I switch linker from gold to bfd.
Here is the minimal sample:
$ echo '#include ' >2.cpp
$ g++ 2.cpp -shared -o 2.so
$ echo '#include ' >1.cpp
$ echo 'int main() { std::cout << 42 << std::endl; }' >>1.cpp
$ g++ 1.cpp -static-libstdc++ -fuse-ld=gold -o 1
$ LD_PRELOAD=./2.so ./1
$ g++ 1.cpp -static-libstdc++ -o 1
$ LD_PRELOAD=./2.so ./1
42
I found out that `this->_M_num_put` in std::cout is nullptr when application is
linked with gold so ios_base::Init::Init() in my app works probably
erroneously.
I tested it with binutils 2.34 (ubuntu 20.04) and binutils 2.30 (a toolchain
built with crosstool-ng). GCC versions was 7.5.0, 8.1.0, 8.4.0, 9.3.0 and
10.1.0.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25708 --- Comment #9 from H.J. Lu --- (In reply to Michael Matz from comment #8) > This breaks at least the perf build from linux kernel 5.7 as nm is used to > construct a symbol list for feeding into ld, which now contains '@' > characters > which aren't liked by ld (of course). See e.g. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887397 > > Is it really a good idea to change the output format of basic tools that > might be > used in machine processing context? (And I note there doesn't seem to be an > cmdline option to get the old behaviour back, so fixing the problem now > entails > further massaging of nm output to cut off /@.*/ ) Is this PR 26302? A patch is at https://sourceware.org/pipermail/binutils/2020-July/112556.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25708 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #8 from Michael Matz --- This breaks at least the perf build from linux kernel 5.7 as nm is used to construct a symbol list for feeding into ld, which now contains '@' characters which aren't liked by ld (of course). See e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887397 Is it really a good idea to change the output format of basic tools that might be used in machine processing context? (And I note there doesn't seem to be an cmdline option to get the old behaviour back, so fixing the problem now entails further massaging of nm output to cut off /@.*/ ) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26346] New: Typo in RISC-V documentation for as
https://sourceware.org/bugzilla/show_bug.cgi?id=26346 Bug ID: 26346 Summary: Typo in RISC-V documentation for as Product: binutils Version: unspecified Status: UNCONFIRMED Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rswarbrick at gmail dot com Target Milestone: --- Created attachment 12752 --> https://sourceware.org/bugzilla/attachment.cgi?id=12752=edit Patch to fix typo The description for -mno-csr-check talks about "cheching" rather than "checking". (Trivial) fix attached. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26339] [aarch64] unknown architectural extensions
https://sourceware.org/bugzilla/show_bug.cgi?id=26339 --- Comment #4 from David Spickett --- >Reading through the rationale at >http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html it looks like LLVM made the conscious step of breaking compatibility with GNU, which is unfortunate. FWIW none of that is implemented yet and I don't think the mismatching names is any intention, it's just due to the timing when they were implemented. (mte is possibly the only one with this issue) Happy to discuss that RFC if you've got specific concerns, it's not set in stone by any means. (I think there was some GNU input but it's been a while) > For the future, it would be great if both the Clang-level and the > assembly-level feature strings in LLVM aligned (and we can ensure they're > aligned with GCC and gas). +1 > For the current inconsistencies, we have some options of resolving the pain. LLVM can add +memtag as an alias for +mte to its "backend feature". Sounds good to me. > The other extension we need to resolve is 'tlb-rmi'. It is a mandatory part > of Armv8.4-A. Do you have an example of what we want this to look like? Is there existing code that uses it with gas perhaps. -- You are receiving this mail because: You are on the CC list for the bug.
