[Bug binutils/25822] Invalid read in process_symbol_table()
https://sourceware.org/bugzilla/show_bug.cgi?id=25822 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-04-15 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25823] Use after free in bfd_hash_lookup(), as demonstrated by nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=25823 Lucille F. Parham changed: What|Removed |Added CC||luciham20 at gmail dot com --- Comment #1 from Lucille F. Parham --- This is a really interesting and informative post. Good job ! keep it up, hope to read your other updates. https://www.reddit.com/r/AndroidtoPCandMac/comments/f79k3w/how_to_easily_play_subway_surfers_in_pc/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25823] Use after free in bfd_hash_lookup(), as demonstrated by nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=25823 --- Comment #2 from Lucille F. Parham --- This is a really interesting and informative post. Good job ! keep it up, hope to read your other updates. https://www.reddit.com/r/AndroidtoPCandMac/comments/f79k3w/how_to_easily_play_subway_surfers_in_pc/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25809] [readelf] --dyn-syms: Display a warning if SHT_DYNSYM and PT_DYNAMIC disagree about the location
https://sourceware.org/bugzilla/show_bug.cgi?id=25809 Lucille F. Parham changed: What|Removed |Added CC||luciham20 at gmail dot com --- Comment #1 from Lucille F. Parham --- I am quite sure they will learn lots of new stuff here than anybody else! http://s3.amazonaws.com/subwaysurfers/index.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 Lucille F. Parham changed: What|Removed |Added CC||luciham20 at gmail dot com --- Comment #1 from Lucille F. Parham --- It is just excellent to know this information. https://chrome.google.com/webstore/detail/subwaysurfers-game/ipdjjecjipdfmjcjopddoldigfolkeje -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25822] Invalid read in process_symbol_table()
https://sourceware.org/bugzilla/show_bug.cgi?id=25822 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=001890e1f9269697f7e0212430a51479271bdab2 commit 001890e1f9269697f7e0212430a51479271bdab2 Author: Alan Modra Date: Wed Apr 15 16:38:01 2020 +0930 PR25822, Invalid read in process_symbol_table PR 25822 * readelf.c (get_num_dynamic_syms): Don't set num_of_syms when reading buckets or chains fails. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25823] Use after free in bfd_hash_lookup(), as demonstrated by nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=25823 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-04-15 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time
https://sourceware.org/bugzilla/show_bug.cgi?id=25406 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #1 from Richard Earnshaw --- Relocations wouldn't help if they were to another shared object. They would guarantee to be more than the offset range supported by those instructions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25823] Use after free in bfd_hash_lookup(), as demonstrated by nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=25823 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ecb51549ab1ec22aba5aaf34b70323cf0b8509a commit 7ecb51549ab1ec22aba5aaf34b70323cf0b8509a Author: Alan Modra Date: Wed Apr 15 18:58:11 2020 +0930 PR25823, Use after free in bfd_hash_lookup PR 25823 * peXXigen.c (_bfd_XXi_swap_sym_in ): Don't use a pointer into strings that may be freed for section name, always allocate a new string. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25823] Use after free in bfd_hash_lookup(), as demonstrated by nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=25823 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.35 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Alan Modra --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25822] Invalid read in process_symbol_table()
https://sourceware.org/bugzilla/show_bug.cgi?id=25822 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.35 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Alan Modra --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613
--- Comment #9 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=95a515681272fa3a79624279c1579cce14ad61c0
commit 95a515681272fa3a79624279c1579cce14ad61c0
Author: Fangrui Song
Date: Wed Apr 15 14:25:08 2020 +0100
Unify the behaviour of ld.bfd and ld.gold with respect to warning about
unresolved symbol references. (PR 24613)
PR binutils/24613
include * bfdlink.h (enum report_method): Delete RM_GENERATE_WARNING and
RM_GENERATE_ERROR. Add RM_DIAGNOSE.
(struct bfd_link_info): Add warn_unresolved_syms.
ld * lexsup.c (parse_args): Change RM_GENERATE_WARNING and
RM_GENERATE_ERROR to RM_DIAGNOSE.
* emultempl/aix.em (ld_${EMULATION_NAME}_emulation): Change
RM_GENERATE_ERROR to RM_DIAGNOSE.
* emultempl/elf.em (ld_${EMULATION_NAME}_emulation): Likewise.
bfd * coff-rs6000.c (xcoff_ppc_relocate_section): Change
RM_GENERATE_ERROR
to RM_DIAGNOSE plus a check of warn_unresolved_syms.
* coff64-rs6000.c (xcoff_ppc_relocate_section): Likewise.
* elf-bfd.h (_bfd_elf_large_com_section): Likewise.
* elf32-m32r.c (m32r_elf_relocate_section): Likewise.
* elf32-score.c (s3_bfd_score_elf_relocate_section): Likewise.
* elf32-score7.c (s7_bfd_score_elf_relocate_section): Likewise.
* elf32-sh.c (sh_elf_relocate_section): Likewise.
* elf32-spu.c (spu_elf_relocate_section): Likewise.
* elf64-hppa.c (elf64_hppa_relocate_section): Likewise.
* elflink.c (elf_link_output_extsym): Likewise.
* elfxx-mips.c (mips_elf_calculate_relocation): Likewise.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Nick Clifton --- (In reply to Fangrui Song from comment #8) Hi Fangrui, > I took a look but this problem seems difficult... He he - you noticed. :-) Still thanks for creating the patch. I have now applied it, along with a few formatting fix ups. > Last, I think the documentation for contributing is lacking. I added > ChangeLog items to each directory my patch touched. Not sure what is the > best approach.. You had it right - one changelog entry per top level directory is the way to go. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/13297] windres.exe is generating invalid RC output.
https://sourceware.org/bugzilla/show_bug.cgi?id=13297 jack changed: What|Removed |Added CC||meave390 at gmail dot com --- Comment #3 from jack --- It is the best post for the all of you players just seen the web site play the here https://heartsgameonline.net hearts card game free online most of the players have to like this post. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/24243] readelf: heap buffer overflow in process_mips_specific
https://sourceware.org/bugzilla/show_bug.cgi?id=24243 jack changed: What|Removed |Added CC||meave390 at gmail dot com --- Comment #4 from jack --- Have to seen the great fun here just seen the web site here https://solitairetimes.com and getting the information for free solitaire games without download i am glad for the given this post for me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25827] New: Null pointer dereferencing in scan_unit_for_symbols() in addr2line
https://sourceware.org/bugzilla/show_bug.cgi?id=25827 Bug ID: 25827 Summary: Null pointer dereferencing in scan_unit_for_symbols() in addr2line Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nguyenmanhdung1710 at gmail dot com Target Milestone: --- Created attachment 12459 --> https://sourceware.org/bugzilla/attachment.cgi?id=12459&action=edit PoC for null pointer dereferencing in addr2line Hi, A null pointer dereferencing was discovered in addr2line (the latest commit 95a5156) in scan_unit_for_symbols(), that can cause a denial of service via a crafted file. To reproduce: addr2line s -e PoC ASAN says: ==16618==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7fd509971746 bp 0x7ffd51517970 sp 0x7ffd515170f8 T0) #0 0x7fd509971745 in strlen (/lib/x86_64-linux-gnu/libc.so.6+0x8b745) #1 0x7fd509f161f8 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x621f8) #2 0x546284 in scan_unit_for_symbols ../../bfd/dwarf2.c:3394 #3 0x547ef6 in comp_unit_maybe_decode_line_info ../../bfd/dwarf2.c:3810 #4 0x547b63 in comp_unit_find_nearest_line ../../bfd/dwarf2.c:3769 #5 0x54d5e2 in _bfd_dwarf2_find_nearest_line ../../bfd/dwarf2.c:5040 #6 0x4b973c in _bfd_elf_find_nearest_line ../../bfd/elf.c:9133 #7 0x4035ea in find_address_in_section ../../binutils/addr2line.c:196 #8 0x421a3e in bfd_map_over_sections ../../bfd/section.c:1377 #9 0x403ae0 in translate_addresses ../../binutils/addr2line.c:274 #10 0x40412e in process_file ../../binutils/addr2line.c:411 #11 0x40460a in main ../../binutils/addr2line.c:525 #12 0x7fd50990682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #13 0x402d98 in _start (/home/dungnguyen/PoCs/binutils_f717994/addr2line+0x402d98) Thanks, Manh Dung -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25827] Null pointer dereferencing in scan_unit_for_symbols() in addr2line
https://sourceware.org/bugzilla/show_bug.cgi?id=25827 Manh-Dung Nguyen changed: What|Removed |Added CC||nguyenmanhdung1710 at gmail dot co ||m -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 Nick Clifton changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED Last reconfirmed||2020-04-15 Ever confirmed|0 |1 --- Comment #9 from Nick Clifton --- Hi Guys, Thanks for the uploads. There were lots of files missing, but I have been able to work around them and I can now reproduce the failures. I do not yet know the cause of the problem, but it is occurring because the following non-dynamic symbols are being detected in a dynamic symbol table: clock_gettime clock_getcpuclockid clock_getres clock_nanosleep clock_settime Do they ring any bells ? Are they special in some way ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #10 from beatlesnut at mac dot com --- Hi, I think those are all core functions of the time stuff, yes? I do believe I cannot resolve 64 bit time types with my current build but I haven't double checked. It's possible the compiler wraps the 64 bit time type to 32 and requires static linkage to do so? Not sure, just spitballing here. Original Message From: nickc at redhat dot com Sent: Wednesday, 15 April 2020 10:19 AM To: br...@mac.com Subject: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host https://sourceware.org/bugzilla/show_bug.cgi?id=25803 Nick Clifton changed: What |Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED |REOPENED Last reconfirmed| |2020-04-15 Ever confirmed|0 |1 --- Comment #9 from Nick Clifton --- Hi Guys, Thanks for the uploads. There were lots of files missing, but I have been able to work around them and I can now reproduce the failures. I do not yet know the cause of the problem, but it is occurring because the following non-dynamic symbols are being detected in a dynamic symbol table: clock_gettime clock_getcpuclockid clock_getres clock_nanosleep clock_settime Do they ring any bells ? Are they special in some way ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #11 from beatlesnut at mac dot com --- It's interesting the n32 build doesn't have this issue. So it must be something to do with wrapping a 64 bit time type to 32 using mabi=32 I think. Shouldn't, or don't, most 32 bit systems have 64 bit time types? Maybe this is the issue since "o"64 and n32 compile fine, and n32 is simply a 32 bit library on a 64 bit host iirc. Original Message From: Gagan Sidhu Sent: Wednesday, 15 April 2020 10:23 AM To: nickc at redhat dot com Subject: Re: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host Hi, I think those are all core functions of the time stuff, yes? I do believe I cannot resolve 64 bit time types with my current build but I haven't double checked. It's possible the compiler wraps the 64 bit time type to 32 and requires static linkage to do so? Not sure, just spitballing here. Original Message From: nickc at redhat dot com Sent: Wednesday, 15 April 2020 10:19 AM To: br...@mac.com Subject: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host https://sourceware.org/bugzilla/show_bug.cgi?id=25803 Nick Clifton changed: What |Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED |REOPENED Last reconfirmed| |2020-04-15 Ever confirmed|0 |1 --- Comment #9 from Nick Clifton --- Hi Guys, Thanks for the uploads. There were lots of files missing, but I have been able to work around them and I can now reproduce the failures. I do not yet know the cause of the problem, but it is occurring because the following non-dynamic symbols are being detected in a dynamic symbol table: clock_gettime clock_getcpuclockid clock_getres clock_nanosleep clock_settime Do they ring any bells ? Are they special in some way ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #12 from Nick Clifton --- Hi beatlesnut, > clock_gettime > clock_getcpuclockid > clock_getres > clock_nanosleep > clock_settime These are all defined in the dynamic symbol table of bglibc/rt/librt_pic.a:clock-compat.os As IFUNCS Ha maybe that is it. Investigating Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #13 from Nick Clifton --- Created attachment 12460 --> https://sourceware.org/bugzilla/attachment.cgi?id=12460&action=edit Proposed patch Hi Guys, Right - the cause is that there are IFUNCS in one of the object files being linked. (In bglib/rt/librt_pic.a:clock-compat.os). As far as I know the MIPS linker does not support IFUNCS. (I may be wrong - I am not a MIPS expert). The uploaded patch changes the ABORT in the linker into a more helpful error message, but it does not actually fix the underlying problem. My guess is that either IFUNC support needs to be added to the linker (by someone who understands MIPS IFUNCS) or else they need to be removed from the link. Please give the patch a try and let me know what you think. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #14 from gagan singh sidhu (gagz, broly, w/e u want) --- hello nick, now i see: cd /Volumes/xtoolshit/bglibc && /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ar cruv libc_nonshared.a `cat csu/stamp.oS iconv/stamp.oS locale/stamp.oS localedata/stamp.oS iconvdata/stamp.oS assert/stamp.oS ctype/stamp.oS intl/stamp.oS catgets/stamp.oS math/stamp.oS setjmp/stamp.oS signal/stamp.oS stdlib/stamp.oS stdio-common/stamp.oS libio/stamp.oS dlfcn/stamp.oS malloc/stamp.oS string/stamp.oS wcsmbs/stamp.oS timezone/stamp.oS time/stamp.oS dirent/stamp.oS grp/stamp.oS pwd/stamp.oS posix/stamp.oS io/stamp.oS termios/stamp.oS resource/stamp.oS misc/stamp.oS socket/stamp.oS sysvipc/stamp.oS gmon/stamp.oS gnulib/stamp.oS wctype/stamp.oS manual/stamp.oS shadow/stamp.oS gshadow/stamp.oS po/stamp.oS argp/stamp.oS nptl/stamp.oS rt/stamp.oS conform/stamp.oS debug/stamp.oS mathvec/stamp.oS support/stamp.oS crypt/stamp.oS nptl_db/stamp.oS inet/stamp.oS resolv/stamp.oS nss/stamp.oS hesiod/stamp.oS sunrpc/stamp.oS nis/stamp.oS nscd/stamp.oS streams/stamp.oS login/stamp.oS elf/stamp.oS stamp.oS` /Applications/Xcode.app/Contents/Developer/usr/bin/make subdir=rt -C rt ..=../ others cd /Volumes/xtoolshit/bglibc && /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ar cruv libc_nonshared.a `cat csu/stamp.oS iconv/stamp.oS locale/stamp.oS localedata/stamp.oS iconvdata/stamp.oS assert/stamp.oS ctype/stamp.oS intl/stamp.oS catgets/stamp.oS math/stamp.oS setjmp/stamp.oS signal/stamp.oS stdlib/stamp.oS stdio-common/stamp.oS libio/stamp.oS dlfcn/stamp.oS malloc/stamp.oS string/stamp.oS wcsmbs/stamp.oS timezone/stamp.oS time/stamp.oS dirent/stamp.oS grp/stamp.oS pwd/stamp.oS posix/stamp.oS io/stamp.oS termios/stamp.oS resource/stamp.oS misc/stamp.oS socket/stamp.oS sysvipc/stamp.oS gmon/stamp.oS gnulib/stamp.oS wctype/stamp.oS manual/stamp.oS shadow/stamp.oS gshadow/stamp.oS po/stamp.oS argp/stamp.oS nptl/stamp.oS rt/stamp.oS conform/stamp.oS debug/stamp.oS mathvec/stamp.oS support/stamp.oS crypt/stamp.oS nptl_db/stamp.oS inet/stamp.oS resolv/stamp.oS nss/stamp.oS hesiod/stamp.oS sunrpc/stamp.oS nis/stamp.oS nscd/stamp.oS streams/stamp.oS login/stamp.oS elf/stamp.oS stamp.oS` mips64el-none-linux-gnu-gcc -mabi=32 -B/cross/bin/ -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 -B/Volumes/xtoolshit/bglibc/csu/ -Wl,--version-script=/Volumes/xtoolshit/bglibc/librt.map -Wl,-soname=librt.so.1 -Wl,-z,relro -Wl,--hash-style=both -Wl,--enable-new-dtags,-z,nodelete -L/Volumes/xtoolshit/bglibc -L/Volumes/xtoolshit/bglibc/math -L/Volumes/xtoolshit/bglibc/elf -L/Volumes/xtoolshit/bglibc/dlfcn -L/Volumes/xtoolshit/bglibc/nss -L/Volumes/xtoolshit/bglibc/nis -L/Volumes/xtoolshit/bglibc/rt -L/Volumes/xtoolshit/bglibc/resolv -L/Volumes/xtoolshit/bglibc/mathvec -L/Volumes/xtoolshit/bglibc/support -L/Volumes/xtoolshit/bglibc/crypt -L/Volumes/xtoolshit/bglibc/nptl -Wl,-rpath-link=/Volumes/xtoolshit/bglibc:/Volumes/xtoolshit/bglibc/math:/Volumes/xtoolshit/bglibc/elf:/Volumes/xtoolshit/bglibc/dlfcn:/Volumes/xtoolshit/bglibc/nss:/Volumes/xtoolshit/bglibc/nis:/Volumes/xtoolshit/bglibc/rt:/Volumes/xtoolshit/bglibc/resolv:/Volumes/xtoolshit/bglibc/mathvec:/Volumes/xtoolshit/bglibc/support:/Volumes/xtoolshit/bglibc/crypt:/Volumes/xtoolshit/bglibc/nptl -o /Volumes/xtoolshit/bglibc/rt/librt.so -T /Volumes/xtoolshit/bglibc/shlib.lds /Volumes/xtoolshit/bglibc/csu/abi-note.o -Wl,--whole-archive /Volumes/xtoolshit/bglibc/rt/librt_pic.a -Wl,--no-whole-archive /Volumes/xtoolshit/bglibc/nptl/libpthread.so -Wl,--start-group /Volumes/xtoolshit/bglibc/libc.so /Volumes/xtoolshit/bglibc/libc_nonshared.a -Wl,--as-needed /Volumes/xtoolshit/bglibc/elf/ld.so -Wl,--no-as-needed -Wl,--end-group /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ld: IFUNC symbol clock_gettime in dynamic symbol table - IFUNCS are not supported /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ld: IFUNC symbol clock_getcpuclockid in dynamic symbol table - IFUNCS are not supported /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ld: IFUNC symbol clock_getres in dynamic symbol table - IFUNCS are not supported /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ld: IFUNC symbol clock_nanosleep in dynamic symbol table - IFUNCS are not supported /Volumes/xtoolshit/hdr3/cross/bin/../lib/gcc/mips64el-none-linux-gnu/9.3.0/../../../../mips64el-none-linux-gnu/bin/ld: IFUNC symbol clock_settime in dynamic symbol table - IFUNCS are not supported which i assume is the desired output. if this is the best solution: i'm surprised no one else p
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 Andreas Schwab changed: What|Removed |Added CC||krissn at op dot pl --- Comment #15 from Andreas Schwab --- *** Bug 22302 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22302] Unable to link glibc-2.24 for mips64-linux-gnuabi64 (assertion fail elfxx-mips.c:9011)
https://sourceware.org/bugzilla/show_bug.cgi?id=22302 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 25803 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #16 from Andreas Schwab --- You need to find out why configure thinks that the toolchain supports %gnu_indirect_function. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #17 from gagan singh sidhu (gagz, broly, w/e u want) --- config.log reports the following relevant variables. seems there's confusion between ld and gcc for indirect_function: libc_cv_gcc_indirect_function=no libc_cv_gcc_unwind_find_fde=yes libc_cv_has_glob_dat=no libc_cv_hashstyle=yes libc_cv_have_sdata_section=yes libc_cv_have_section_quotes=no libc_cv_idn=no libc_cv_insert=yes libc_cv_ld_gnu_indirect_function=yes -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803
--- Comment #18 from gagan singh sidhu (gagz, broly, w/e u want) ---
looking at the binutils and searching for the keyword, is it possible 'gas' is
the problem?:
GagansMacPro:mkbu Gagan$ grep -rn gnu_indirect_function .
Binary file ./gas/as-new matches
Binary file ./gas/config/obj-elf.o matches
./gold/config.log:907:| __asm__(".type invoke, %gnu_indirect_function");
looking at the output for gas/config/obj-elf.c:
else if (strcmp (type_name, "gnu_indirect_function") == 0
|| strcmp (type_name, "10") == 0
|| strcmp (type_name, "STT_GNU_IFUNC") == 0)
{
struct elf_backend_data *bed;
bed = (struct elf_backend_data *) get_elf_backend_data (stdoutput);
if (bed->elf_osabi == ELFOSABI_NONE)
bed->elf_osabi = ELFOSABI_GNU;
else if (bed->elf_osabi != ELFOSABI_GNU
&& bed->elf_osabi != ELFOSABI_FREEBSD)
as_bad (_("symbol type \"%s\" is supported only by GNU "
"and FreeBSD targets"), type_name);
elf_tdata (stdoutput)->has_gnu_osabi |= elf_gnu_osabi_ifunc;
type = BSF_FUNCTION | BSF_GNU_INDIRECT_FUNCTION;
}
it seems using the 'none' causes bed->elf_osabi = ELFOSABI_GNU, whereas it
should be falling into the else if condition? sorry i don't know this code
well. i know the tuple is a 'none-linux-gnu' though and i'm curious if that
causes it to be assigned ELFOSABI_NONE first, and then ELFOSABI_GNU, or if it
is assigned ELFOSABI_GNU initially.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #19 from gagan singh sidhu (gagz, broly, w/e u want) --- is it possible havving something like bed->elf_target_id == MIPS_ELF_DATA in the "else if" could fix this/ i haen't tested yet i'm practicing, but i am wondering if making the else if: else if ( (bed->elf_osabi != ELFOSABI_GNU && bed->elf_osabi != ELFOSABI_FREEBSD) || bed->elf_target_id == MIPS_ELF_DATA) would fix it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803
--- Comment #20 from gagan singh sidhu (gagz, broly, w/e u want) ---
if (bed->elf_osabi == ELFOSABI_NONE &&
bed->target_id != MIPS_ELF_DATA)
bed->elf_osabi = ELFOSABI_GNU;
else if (bed->target_id == MIPS_ELF_DATA)
as_bad (_("symbol type \"%s\" is not supported by "
"MIPS targets"), type_name);
else if (bed->elf_osabi != ELFOSABI_GNU
&& bed->elf_osabi != ELFOSABI_FREEBSD)
as_bad (_("symbol type \"%s\" is supported only by GNU "
"and FreeBSD targets"), type_name);
libc_cv_gcc_builtin_redirection=yes
libc_cv_gcc_incompatible_alias=yes
libc_cv_gcc_indirect_function=no
libc_cv_gcc_unwind_find_fde=yes
libc_cv_has_glob_dat=no
libc_cv_hashstyle=yes
libc_cv_have_sdata_section=yes
libc_cv_have_section_quotes=no
libc_cv_idn=no
libc_cv_insert=yes
libc_cv_ld_gnu_indirect_function=no
libc_cv_linux320='3.2.0 or later'
produces the desired output. probably could collapse the second else if into
the third given that the first condition (where we check for none) has an "and"
to ensure that it's not MIPS (otherwise it gets set to GNU and this is where
the problem lies).
open to tidying, but i think mr SCHWIZZAB helped us cliffz
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host
https://sourceware.org/bugzilla/show_bug.cgi?id=25803 --- Comment #21 from gagan singh sidhu (gagz, broly, w/e u want) --- compiles cleanly. so this is also another plausible fix. let's get something upstream pronto pls -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time
https://sourceware.org/bugzilla/show_bug.cgi?id=25406 Tamar Christina changed: What|Removed |Added CC||tnfchris at sourceware dot org --- Comment #2 from Tamar Christina --- To add to what Richard said having the assembler emits much better error messages for these cases. If we emitted the relocations here and have the linker resolve them when not -shared the error would be a generic truncation error. Ultimately you wouldn't want to write code like this using pcrel instructions if you want to write PIC code. I'm also worried about previously working code that can fail if it now ends up in a shared object with relocation and it's preempted by another symbol which will more than likely be out of range. So I also don't think we should emit relocations here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time
https://sourceware.org/bugzilla/show_bug.cgi?id=25406 --- Comment #3 from Fangrui Song --- Alternatively, we can reject such non-STB_LOCAL labels when they may be preemptible. The scheme will still be consistent with the rest of ELF models and architectures. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #8 from Stephen Casner --- Created attachment 12461 --> https://sourceware.org/bugzilla/attachment.cgi?id=12461&action=edit Patch for test to work with pdp11-aout I found that my proposed pr18963.s got an assembly error with target cris-aout because pseudo-op .bss is not defined. So I changed to use .lcomm instead, and removed the _data and _bss symbols that were not needed, then the output is the same as for the old script except for the different value for E and different section associations for some symbols. With the revised pr18963.s the test passes with targets x86_64-linux-gnu, i386-elf32, cris-aout, z80-coff and pdp11-aout. I believe the attached patch is complete for commit. Suggested log: Fix test ld-scripts/pr18963 to work on targets such as pdp11-aout where having the linker script modify the section sizes causes the output format to be invalid. Also reduce the size of the test addresses to fit in 16-bits. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/18963] Addition is not commutative
https://sourceware.org/bugzilla/show_bug.cgi?id=18963 --- Comment #9 from Stephen Casner --- (In reply to Stephen Casner from comment #8) ... > the output is the same as for the old script except for the different value > for E and different section associations for some symbols. To clarify, those differences are when running the test script against commit a8aa551e5abde13e063beb32ec0366bdc6008d71 from before the code change, as described near the end of comment 6. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 21206 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in make_qualified_name
Updates: Labels: -restrict-view-commit Comment #3 on issue 21206 by sheriffbot: binutils:fuzz_readelf: Direct-leak in make_qualified_name https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21206#c3 This bug has been fixed for 30 days. 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 21226 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in get_data
Updates: Labels: -restrict-view-commit Comment #3 on issue 21226 by sheriffbot: binutils:fuzz_readelf: Direct-leak in get_data https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21226#c3 This bug has been fixed for 30 days. 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 21210 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in get_data
Updates: Labels: -restrict-view-commit Comment #3 on issue 21210 by sheriffbot: binutils:fuzz_readelf: Direct-leak in get_data https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21210#c3 This bug has been fixed for 30 days. 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 21191 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in xmalloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 21191 by sheriffbot: binutils:fuzz_readelf: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21191#c3 This bug has been fixed for 30 days. 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 21171 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in xmalloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 21171 by sheriffbot: binutils:fuzz_readelf: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21171#c3 This bug has been fixed for 30 days. 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 21205 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in xmalloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 21205 by sheriffbot: binutils:fuzz_readelf: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21205#c3 This bug has been fixed for 30 days. 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 21169 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in xmalloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 21169 by sheriffbot: binutils:fuzz_readelf: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21169#c3 This bug has been fixed for 30 days. 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 21254 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in xmalloc
Updates: Labels: -restrict-view-commit Comment #3 on issue 21254 by sheriffbot: binutils:fuzz_readelf: Direct-leak in xmalloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21254#c3 This bug has been fixed for 30 days. 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 21225 in oss-fuzz: binutils:fuzz_readelf: Out-of-memory in fuzz_readelf
Updates: Labels: -restrict-view-commit Comment #3 on issue 21225 by sheriffbot: binutils:fuzz_readelf: Out-of-memory in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21225#c3 This bug has been fixed for 30 days. 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 binutils/25828] New: nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=25828 Bug ID: 25828 Summary: nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Presumably since the creation of the pdp11-aout target 20 years ago, a symbol defined in a linker script that is referenced as a global variable in a source file will be shown as undefined by nm: T __start T _start T main t pr14962a.o 0002 t pr14962b.o T start U x Separately, symbols with the MSB set will be shown sign-extended to 64 bits, whereas PDP11 addresses are only 16 bits. A DATA_LENGTH 1000 A DATA_ORIGIN 8000 A TXT_LENGTH 0100 A TXT_ORIGIN 1004 D data_end 1000 T data_start 1000 D data_symbol 1000 D fred 0104 T text_end 0100 T text_start 0100 T text_symbol 0100 t tmpdir/script.o 8100 D tred -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] New: Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 Bug ID: 25829 Summary: Several ld tests fail for 16-bit targets like pdp11-aout Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Several tests in ld/testsuite/ld-scripts fail for the pdp11-aout target because address and/or size constants used in the tests are larger than will fit in a 16-bit address space. The choice of those constants is arbitrary, though, often just following the example test case that was submitted when the bug was filed. None of those tests are performing an operation where the numerical size of the constant is significant. Thus, these tests can be fixed for targets with 16-bit address spaces just by scaling down the constants. A related problem is the use of .long for references to test symbols. That requires a 32-bit relocation, which a 16-bit target can't do. Changing to .dc.a allows the relocation to fit the target address size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25828] nm for pdp11-aout shows symbols undefined or sign-extended to 64 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=25828 --- Comment #1 from Stephen Casner --- Created attachment 12462 --> https://sourceware.org/bugzilla/attachment.cgi?id=12462&action=edit Patch to fix undefined symbols and sign extension When bfd/pdp11.c was copied from bfd/aoutx.h, the #defines for external symbol types N_TEXT etc. were #undef'd and then #define'd with new values. But N_STAB was not changed even though the new value for N_EXT overlapped with it. This caused aout_link_write_symbols() to treat global symbols referenced in the source but defined in a linker script as undefined. Separately, in translate_symbol_table() the 16-bit symbol values were sign extended to unsigned long (e.g., 64 bits) when they really should be treated as unsigned so the value remains 16 bits. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #1 from Stephen Casner --- Created attachment 12463 --> https://sourceware.org/bugzilla/attachment.cgi?id=12463&action=edit Patch to fix tests After the patch for reopened PR 18963 and the patch for PR 25828 and this patch are applied the ld testsuite will run for target pdp11-aout with no unexpected failures (also no failures introduced by these patches for targets x86_64-linux-gnu, i386-elf32, cris-aout and z80-coff). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] New: pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 Bug ID: 25830 Summary: pdp11-aout target does not support gdb, gdbserver, gprof Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: casner at acm dot org Target Milestone: --- Since the pdp11-aout target does not support gdb, gdbserver or gprof these should be excluded in configure. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 --- Comment #1 from Stephen Casner --- Created attachment 12464 --> https://sourceware.org/bugzilla/attachment.cgi?id=12464&action=edit Patch for configure Add gdb and gprof to noconfigdirs for pdp11-*-*; gdbserver is handled separately by not including a configuration for pdp11 in configure.srv. -- You are receiving this mail because: You are on the CC list for the bug.
