[Bug gprofng/29646] New: Various warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29646 Bug ID: 29646 Summary: Various warnings Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: mliska at suse dot cz Target Milestone: --- Please fix the following warnings: ../../../gprofng/libcollector/iolib.c:151:32: warning: the comparison will always evaluate as ‘false’ for the address of ‘__collector_exp_dir_name’ will never be NULL [-Waddress] ../../../gprofng/libcollector/linetrace.c:835:28: warning: the comparison will always evaluate as ‘false’ for the address of ‘new_exp_name’ will never be NULL [-Waddress] ../../../gprofng/src/Settings.cc:1260:23: warning: comparing the result of pointer addition ‘(colon + 1)’ and NULL [-Waddress] ../../../gprofng/src/checks.cc:329:29: warning: the address of ‘utsname::machine’ will never be NULL [-Waddress] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29579] ld: .libs/libgp_collector_la-mmaptrace.o (symbol from plugin): in function `dlclose': on i586
https://sourceware.org/bugzilla/show_bug.cgi?id=29579 --- Comment #2 from Martin Liska --- Any progress on this please, it's still breaking i586 target? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29647] New: [Infinite Loop]: objdump(version 2.39.50.20221003, commit e1fc9bcf)
https://sourceware.org/bugzilla/show_bug.cgi?id=29647
Bug ID: 29647
Summary: [Infinite Loop]: objdump(version 2.39.50.20221003,
commit e1fc9bcf)
Product: binutils
Version: 2.40 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: chkunq at gmail dot com
Target Milestone: ---
Created attachment 14374
--> https://sourceware.org/bugzilla/attachment.cgi?id=14374&action=edit
An input file that triggers an infinite loop in objdump.
# Crash Inputs
The file that triggers the bug is attached in attachment.
# Bug Description
When the given file is used as input, `objdump` cannot finish execution within
600s.
Via debugging, I eventually confirm that the given input file triggered an
infinite loop in `objdump`.
```
(gdb) bt
#0 print_line (p=0x724f40, linenum=175019134) at ./objdump.c:2074
#1 0x004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
#2 0x0041114a in show_line (abfd=0x707690, section=0x70a998,
addr_offset=258) at ./objdump.c:2292
#3 0x0040f1d2 in disassemble_bytes (inf=0x7fffdd58,
disassemble_fn=0x467200 , insns=true, data=0x721250
"\363\017\036\372\061\355I\211\321^H\211\342H\203\344\360PTI\307\300\300\030@",
start_offset=240, stop_offset=336, rel_offset=0,
relppp=0x7fffdc38, relppend=0x0) at ./objdump.c:3314
#4 0x0040c9b3 in disassemble_section (abfd=0x707690, section=0x70a998,
inf=0x7fffdd58) at ./objdump.c:4007
#5 0x004b2b37 in bfd_map_over_sections (abfd=0x707690,
operation=0x40bbb0 , user_storage=0x7fffdd58) at
section.c:1373
#6 0x00408d21 in disassemble_data (abfd=0x707690) at ./objdump.c:4151
#7 0x0040715e in dump_bfd (abfd=0x707690, is_mainfile=true) at
./objdump.c:5563
#8 0x00406a29 in display_object_bfd (abfd=0x707690) at
./objdump.c:5626
#9 0x004069e3 in display_any_bfd (file=0x707690, level=0) at
./objdump.c:5712
#10 0x0040624e in display_file (filename=0x7fffe3d4
"./objdump/hangs-600/hangs/000", target=0x0, last_file=true) at
./objdump.c:5733
#11 0x00404e43 in main (argc=3, argv=0x7fffe118) at
./objdump.c:6129
(gdb) f 1
#1 0x004115f3 in dump_lines (p=0x724f40, start=175019135,
end=4294967295) at ./objdump.c:2093
2093 print_line (p, start);
(gdb) list
2088{
2089 if (p->map == NULL)
2090return;
2091 while (start <= end)
2092{
2093 print_line (p, start);
2094 start++;
2095}
2096}
2097
(gdb) p end == -1
$1 = 1
```
As the type of `end` is u32, the looping could not terminate if `end`== -1 ==
0x (INTEGER OVERFLOW).
After backtracing the call stack, I found that the value of `end` comes from
`u32 linenumber` in function `show_line(...) :objdump.c:2106`, and the value of
`linenumber` is defined in function `bfd_find_nearest_line_discriminator(...,
&linenumber,...) :objdump.c:2155`. Although the value comes from from library
`bfd`, I think it is still necessary to check the value of the linenumber after
getting it.
`assert( linenumber != 0x && "linenumber cannot be -1.")`
# How to Reproduce
The aforementioned bug can be stably reproduced in version 2.39.50 (commit id
db0f0fcb.
1. Download the binutils-gdb source code with the [official
link](https://gitlab.com/libtiff/libtiff).
2. Build binutils-gdb with clang/clang++ (10.0.0-4ubuntu1),.
3. Execute objdump with the provided input files.
- eg: `/data/program/binutils-gdb/orig/bin/objdump -S `
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/29107] gas testsuite parallel jobs fail (gprofng?)
https://sourceware.org/bugzilla/show_bug.cgi?id=29107 Xi Ruoyao changed: What|Removed |Added CC||xry111 at xry111 dot site --- Comment #2 from Xi Ruoyao --- (In reply to Nick Clifton from comment #1) > (In reply to Toolybird from comment #0) > > > Any thoughts? Thanks. > > Don't run the testsuites in parallel ? :-) > > OK, so not helpful. Instead some questions - if you run the builds in > parallel, but then the checks sequentially, does everything work. How about > the other way around (sequential builds, parallel tests) ? > > The thing that struck me about the error message was that it looks like the > opcodes library is in the process of being built whilst the tests are > running. So maybe - just a theory - the gprofng testsuite is triggering a > *re-build* of the opcodes library for some reason. (Because of some strange > makefile dependency maybe ?) The reason is gprofng tests installs libopcodes.so into a chroot environment, and libtool (a stupid thing trying to be *too* clever, I must add) relinks a shared object being installed. > Another wild guess - maybe adding the .NOTPARALLEL: pseudo-target to the > gprofng Makefile.am would help ? Just before the check-DEJAGNU: target ? I'll try. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29107] gas testsuite parallel jobs fail (gprofng?)
https://sourceware.org/bugzilla/show_bug.cgi?id=29107 --- Comment #3 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #2) > (In reply to Nick Clifton from comment #1) > > Another wild guess - maybe adding the .NOTPARALLEL: pseudo-target to the > > gprofng Makefile.am would help ? Just before the check-DEJAGNU: target ? > > I'll try. Hmm, it does not work for me. AFAIK it's a race between check-gas and check-gprofng, so changing something in gprofng subdirectory won't help... -- You are receiving this mail because: You are on the CC list for the bug.
Re: Report a bug of binutils-2.38
Hi bjchan9an, There is an uncontrolled stack recursion vulnerability in binutils-2.38, which allows stack consumption in demangle_path_maybe_open_generics(). As Alan said, we are really only interested in bugs triggered by fuzzed binaries if they are reported against the current mainline code. Given the trouble that I know that you have had in reporting this problem however I thought that I would add a few more details: 1. As it happens the string demangling code is part of the libiberty library which actually maintained by the GCC project not us. (The binutils project makes use of the code, but it does not maintain the code). Hence bug reports about demangling should be sent to the gcc mailing list. 2. This problem - with the Rust demangler - has already been reported and fixed. If you try the current mainline GNU binutils sources you should find that the stack exhaustion does not occur. Cheers Nick
[Bug gprofng/29646] Various warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29646 Kurt Goebel changed: What|Removed |Added CC||kurt.goebel at oracle dot com Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29107] gas testsuite parallel jobs fail (gprofng?)
https://sourceware.org/bugzilla/show_bug.cgi?id=29107 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |vladimir.mezentsev at oracle dot c ||om Component|gas |gprofng --- Comment #4 from Nick Clifton --- (In reply to Xi Ruoyao from comment #3) > Hmm, it does not work for me. AFAIK it's a race between check-gas and > check-gprofng, so changing something in gprofng subdirectory won't help... Agreed. This appears to be an artifact of the gprofng's testing environment. In particular in gprofng/testsuite/config/default.exp there is: # Make a temporary install dir to run gprofng from, and point at it remote_exec host "sh -c \"rm -rf tmpdir; mkdir -p tmpdir; $MAKE -C .. install-gprofng program_transform_name= DESTDIR=`pwd`/tmpdir/root\"" Which is probably the trigger. I am reassigning this PR to gprofng in the hopes that one of the maintainers will know why the installation is necessary and may be able to come up with a workaround. -- You are receiving this mail because: You are on the CC list for the bug.
ARMV7a: selected processor does not support requested special purpose register
Hi All, We have problem to compile the following asm https://godbolt.org/z/hejMPoW69 and asm error out with the subject message . Is mrs for float special register not valid on cortex-a9 ? Thank you ~Umesh
ARMV7a: selected processor does not support requested special purpose register
Hi All, We have problem to compile the following asm https://godbolt.org/z/hejMPoW69 and asm error out with the subject message . Is mrs for float special register not valid on cortex-a9 ? Thank you ~Umesh
Re: ARMV7a: selected processor does not support requested special purpose register
On 03/10/2022 15:41, Umesh Kalappa via Binutils wrote: Hi All, We have problem to compile the following asm https://godbolt.org/z/hejMPoW69 and asm error out with the subject message . Is mrs for float special register not valid on cortex-a9 ? Thank you ~Umesh that's because the instruction you want is vmrs r4, fpscr R.
Re: ARMV7a: selected processor does not support requested special purpose register
On 03/10/2022 16:48, Richard Earnshaw via Binutils wrote: On 03/10/2022 15:41, Umesh Kalappa via Binutils wrote: Hi All, We have problem to compile the following asm https://godbolt.org/z/hejMPoW69 and asm error out with the subject message . Is mrs for float special register not valid on cortex-a9 ? Thank you ~Umesh that's because the instruction you want is vmrs r4, fpscr R. Also note that the fmrrs mnemonic is not part of the UAL (unified assembly language) specification - it was deprecated a long time ago. The correct names these days all start with a V - the disassembler output shows the modern form. The legacy name for vmrs was fmrx. R.
[Bug ld/29649] New: ld: Insufficient checking that BFD backend is suitable for ld emulation on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=29649
Bug ID: 29649
Summary: ld: Insufficient checking that BFD backend is suitable
for ld emulation on aarch64
Product: binutils
Version: 2.40 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Configuring with --target=aarch64-none-elf --enable-targets=all --disable-gdb,
I see:
$ cat t.s
.global _start
_start:
nop
$ gas/as-new t.s -o t.o
$ ld/ld-new t.o --oformat pei-aarch64-little
ld/ld-new: BFD (GNU Binutils) 2.39.50.20221003 assertion fail
elfnn-aarch64.c:4829
The assertion failing here is:
BFD_ASSERT (is_aarch64_elf (output_bfd));
the problem is we call the AArch64 ELF backend function
bfd_elfNN_aarch64_set_options from the emulation hook
aarch64_elf_create_output_section_statements, but the actual BFD backend in use
for the output BFD is the pei-aarch64-little backend.
I think we need to be stricter about ensuring we only allow valid combinations
of BFD backend and ld emulation. If we instead set the BFD backend to
mach-o-arm64, we reject it with this error:
$ ld/ld-new t.o --oformat mach-o-arm64
ld/ld-new: error: cannot change output format whilst linking AArch64 binaries
but it seems this is only by accident, since the check that handles this is
looking specifically for the string "aarch64" in the BFD target, but this
target uses "arm64" instead. The check in ld/emultempl/aarch64elf.em is:
/* This is a convenient point to tell BFD about target specific flags.
After the output has been created, but before inputs are read. */
static void
aarch64_elf_create_output_section_statements (void)
{
if (strstr (bfd_get_target (link_info.output_bfd), "aarch64") == NULL)
{
/* The arm backend needs special fields in the output hash structure.
These will only be created if the output format is an arm format,
hence we do not support linking and changing output formats at the
same time. Use a link followed by objcopy to change output formats.
*/
einfo (_("%F%P: error: cannot change output format "
"whilst linking %s binaries\n"), "AArch64");
return;
}
Overall it seems we need to tidy up how non-ELF object formats are handled on
AArch64 (specifically the relationship between ld emulations and BFD backends).
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 49000 in oss-fuzz: binutils:fuzz_objcopy: Direct-leak in xcalloc
Updates: Labels: Deadline-Approaching Comment #2 on issue 49000 by sheriffbot: binutils:fuzz_objcopy: Direct-leak in xcalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49000#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 48997 in oss-fuzz: binutils:fuzz_as: Null-dereference READ in notes_calloc
Updates: Labels: Deadline-Approaching Comment #3 on issue 48997 by sheriffbot: binutils:fuzz_as: Null-dereference READ in notes_calloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48997#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 48768 in oss-fuzz: binutils:fuzz_ranlib_simulation: Direct-leak in bfd_malloc
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 48768 by sheriffbot: binutils:fuzz_ranlib_simulation: Direct-leak in bfd_malloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48768#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 48766 in oss-fuzz: binutils:fuzz_addr2line: Direct-leak in bfd_malloc
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 48766 by sheriffbot: binutils:fuzz_addr2line: Direct-leak in bfd_malloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48766#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gprofng/29579] ld: .libs/libgp_collector_la-mmaptrace.o (symbol from plugin): in function `dlclose': on i586
https://sourceware.org/bugzilla/show_bug.cgi?id=29579 --- Comment #3 from Vladimir Mezentsev --- I have a fix. I just started our tests. If there will be no regression I send diffs for review tomorrow. -- You are receiving this mail because: You are on the CC list for the bug.
Re: ARMV7a: selected processor does not support requested special purpose register
Thank you Richard for the information and do you please point us to the reference ,which states the same ? Quick grep doesn't helped us ,Thank you again ~Umesh On Mon, Oct 3, 2022 at 9:24 PM Richard Earnshaw wrote: > > > > On 03/10/2022 16:48, Richard Earnshaw via Binutils wrote: > > > > > > On 03/10/2022 15:41, Umesh Kalappa via Binutils wrote: > >> Hi All, > >> > >> We have problem to compile the following asm > >> https://godbolt.org/z/hejMPoW69 > >> > >> and asm error out with the subject message . > >> > >> Is mrs for float special register not valid on cortex-a9 ? > >> > >> Thank you > >> ~Umesh > > > > that's because the instruction you want is > > > > vmrs r4, fpscr > > > > R. > > Also note that the fmrrs mnemonic is not part of the UAL (unified > assembly language) specification - it was deprecated a long time ago. > The correct names these days all start with a V - the disassembler > output shows the modern form. > > The legacy name for vmrs was fmrx. > > R.
