[Bug ld/24832] New: mips: convert from data to object always generate MIPS I
https://sourceware.org/bugzilla/show_bug.cgi?id=24832
Bug ID: 24832
Summary: mips: convert from data to object always generate MIPS
I
Product: binutils
Version: 2.33 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: syq at debian dot org
Target Milestone: ---
$ echo "abc" > xx.dat
$ mips64el-linux-gnuabi64-ld -r -b binary xx.dat -o xx.o
$ file xx.o
xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped
while to link xx.o with real mips64 objects, it fails:
Index: binutils-2.32.51.20190707/bfd/elfxx-mips.c
===
--- binutils-2.32.51.20190707.orig/bfd/elfxx-mips.c
+++ binutils-2.32.51.20190707/bfd/elfxx-mips.c
@@ -12193,6 +12193,11 @@ mips_set_isa_flags (bfd *abfd)
switch (bfd_get_mach (abfd))
{
default:
+ if (ABI_N32_P (abfd) || ABI_64_P (abfd))
+val = E_MIPS_ARCH_3;
+ else
+val = E_MIPS_ARCH_1;
+ break;
case bfd_mach_mips3000:
val = E_MIPS_ARCH_1;
break;
can convert it to:
xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS-III version 1 (SYSV), not stripped
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932287
https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=mips64el&ver=2.61.1-2&stamp=1563280987&raw=0
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24829] readelf: interger overflow in apply_relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=24829 tfx changed: What|Removed |Added CC||tfx_sec at hotmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23573] "Too many open files" and binutils 2.31.1-1
https://sourceware.org/bugzilla/show_bug.cgi?id=23573 --- Comment #17 from Nick Clifton --- Hi Benjamin, > https://www.dropbox.com/s/jyaapql2gj1r7br/gcc-win64.tar.gz?dl=0 Thanks - I was able to download the tarball from there. Unfortunately I do not have a copy of the /usr/lib/x86_64-w64-mingw32/lib/crt2.o object file. (I am using an installed x86_64-mingw32 cross compiler running under Linux). When I commented that part out from the build command line however I was able to run the entire command, including using the plugin, and not get an error message about too many open files. (I did get the messages about the missing libraries however). I suspect therefore that part of the problem is that a native mingw32 build system has a lower limit on the maximum number of files that can be open at any one time. > So removing the linker plugin arguments makes the command work. OK, so this is significant. The implication therefore is that it is the plugin itself which is opening files and then not closing them. (Or maybe the plugin calls a linker function which opens a file, but then the plugin does call the corresponding linker function to close the file). It also means that compiling without -flto is an option for a workaround. Unfortunately the libtlo plugin is actually part of the gcc project, rather than the binutils project, so you may need to refile this bug report there, sorry. In fact it may be that there is no simple solution. It may well be that linking large projects with LTO enabled on a system with a low limit on the number of open files is just not going to work. :-( Not what you want to hear, I know, but it certainly is starting to look like this is the case. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24836] New: --as-needed leaves unused direct dependencies
https://sourceware.org/bugzilla/show_bug.cgi?id=24836 Bug ID: 24836 Summary: --as-needed leaves unused direct dependencies Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: crusader.mike at gmail dot com Target Milestone: --- I have a binary that is linked like this: /opt/rh/devtoolset-8/root/usr/bin/g++ -O3 -DNDEBUG -Wl,--gc-sections -s -Wl,--as-needed -o procmon.e -Wl,-rpath,/usr/local/lib64 /usr/local/lib64/libxalan-c.so /usr/local/lib64/libxerces-c.so (1) curl z aws-cpp-sdk-s3 aws-cpp-sdk-core ssl crypto aws-c-event-stream aws-c-common aws-checksums azurestorage uuid xml2 zma cpprest boost_log boost_log_setup boost_filesystem boost_thread boost_date_time boost_regex boost_chrono boost_atomic (2) -lcrypt -lrt -lm -ldl -pthread but (even though --as-needed is present) ldd still reports unused dependencies: $ ldd -u -r procmon.e Unused direct dependencies: /usr/local/lib64/libxalan-c.so.111 /lib64/libcrypt.so.1 /lib64/libm.so.6 Info: CentOS 7 g++ (GCC) 8.2.1 20180905 (Red Hat 8.2.1-3) GNU ld version 2.30-47.el7 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23573] "Too many open files" and binutils 2.31.1-1
https://sourceware.org/bugzilla/show_bug.cgi?id=23573
--- Comment #18 from Benjamin Redelings
---
Hi Nick,
Thank you so much for looking into this.
I reran the exact same command and now it works with the linker plugin just
fine. I also check using /proc, and the linker process has about 30 open
files. I have done some package upgrades, and it looks like a patch for Debug
bug 928214 ("Configure LTO support correctly",
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928214) may be the one that
fixed the problem.
In any case, for the benefit of any future triggerers of this bug:
1. The problem is probably with GCC, not binutils.
2. I was not using native mingw binutils, I was using Debian's linux-native
cross compiler.
Referring to the bug report above, one possible explanation is that
* the LTO plugin was misconfigured in autoconf
* this caused gcc to fall back to the lto-wrapper helper and NOT use the linker
plugin
* the lto-wrapper help creates N open file descriptors for an archive
containing N objects.
* the actual lto-plugin works fine.
This is somewhat speculative, but might hopefully give someone a path to
explore if they run into this again.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24837] New: readelf: heap buffer overflow
https://sourceware.org/bugzilla/show_bug.cgi?id=24837 Bug ID: 24837 Summary: readelf: heap buffer overflow Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rmirzazadeh at gmail dot com Target Milestone: --- Created attachment 11917 --> https://sourceware.org/bugzilla/attachment.cgi?id=11917&action=edit readelf-heapoverflow-poc I encountered a heap buffer overflow in `readelf` during my fuzz testing. (GNU readelf (GNU Binutils) 2.32.51.20190722) To reproduce ( I assumed the binary is compiled with ASan) ./readelf -A PoC Here is the ASan output: readelf: Warning: Section 1 has an out of range sh_link value of 12 readelf: Warning: Section 2 has an out of range sh_link value of 12 readelf: Warning: Section 3 has an out of range sh_link value of 23 readelf: Error: Section 1 has invalid sh_entsize of 0004 readelf: Error: (Using the expected size of 16 for the rest of this dump) readelf: Error: Reading 116 bytes extends past end of file for symbols readelf: Error: no .dynamic section in the dynamic segment readelf: Warning: Virtual address 0x6f not located in any PT_LOAD segment. Section '^�ELF<80> ^A' contains 1 entry: = ==20157==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200140 at pc 0x0060b187 bp 0x7ffdbbacb4e0 sp 0x7ffdbbacb4d8 READ of size 1 at 0x60200140 thread T0 #0 0x60b186 (/tmp/binutils-gdb/binutils/readelf+0x60b186) #1 0x5a5e7c (/tmp/binutils-gdb/binutils/readelf+0x5a5e7c) #2 0x54c877 (/tmp/binutils-gdb/binutils/readelf+0x54c877) #3 0x52c12e (/tmp/binutils-gdb/binutils/readelf+0x52c12e) #4 0x51b0c7 (/tmp/binutils-gdb/binutils/readelf+0x51b0c7) #5 0x5198cf (/tmp/binutils-gdb/binutils/readelf+0x5198cf) #6 0x7fadfc83782f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #7 0x41a828 (/tmp/binutils-gdb/binutils/readelf+0x41a828) 0x60200140 is located 0 bytes to the right of 16-byte region [0x60200130,0x60200140) allocated by thread T0 here: #0 0x4dea58 (/tmp/binutils-gdb/binutils/readelf+0x4dea58) #1 0x65bc07 (/tmp/binutils-gdb/binutils/readelf+0x65bc07) #2 0x5b5299 (/tmp/binutils-gdb/binutils/readelf+0x5b5299) #3 0x5a5032 (/tmp/binutils-gdb/binutils/readelf+0x5a5032) #4 0x54c877 (/tmp/binutils-gdb/binutils/readelf+0x54c877) #5 0x52c12e (/tmp/binutils-gdb/binutils/readelf+0x52c12e) #6 0x51b0c7 (/tmp/binutils-gdb/binutils/readelf+0x51b0c7) #7 0x5198cf (/tmp/binutils-gdb/binutils/readelf+0x5198cf) #8 0x7fadfc83782f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: heap-buffer-overflow (/tmp/binutils-gdb/binutils/readelf+0x60b186) Shadow bytes around the buggy address: 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff8000: fa fa fd fa fa fa 00 04 fa fa 00 04 fa fa 00 04 0x0c047fff8010: fa fa 00 01 fa fa fd fa fa fa fd fd fa fa 00 00 =>0x0c047fff8020: fa fa 00 01 fa fa 00 00[fa]fa fa fa fa fa fa fa 0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==20157==ABORTING -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24838] New: /etc/ld.so.preload.d drop-in configuration folder support
https://sourceware.org/bugzilla/show_bug.cgi?id=24838 Bug ID: 24838 Summary: /etc/ld.so.preload.d drop-in configuration folder support Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: adrelanos at riseup dot net Target Milestone: --- File /etc/ld.so.preload can be used to preload shard objects but there is no /etc/ld.so.preload.d drop-in configuration folder supported yet. Modifying /etc/ld.so.preload directly is appropriate for system administrators but not for linux distributions. A configuration file can only be owned by one package at the same time. A package that shipped a /etc/ld.so.preload file might overwrite the loal system administator's changes. Therefore as you may know many applications support configuration drop-in folders. Examples are /etc/default/grub.d /etc/grub.d /etc/profile.d /etc/X11/Xsession.d and many more. Could you please add a new feature to parse /etc/ld.so.preload.d for configuration snippets? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
