[Bug gas/22492] Incorrect note section alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22492 --- Comment #8 from crunte at astraphoto dot smart-soft.eu --- Good day. You should take a good look at all the numbers I forward here and direct me the modified info. https://meetinsrilanka.com/molestias-et/iste.zip -Original Message- On Wednesday, 29 November 2017, 09:34, wrote: > Good day. > > You should take a good look at all the numbers I forward here and direct me > the modified info. > > https://meetinsrilanka.com/molestias-et/iste.zip -- You are receiving this mail because: You are on the CC list for the bug.
Issue 35826 in oss-fuzz: binutils:fuzz_readelf: Timeout in fuzz_readelf
Updates: Labels: Deadline-Approaching Comment #2 on issue 35826 by sheriffbot: binutils:fuzz_readelf: Timeout in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35826#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.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #23 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7d53105d6ed984aec255fa0eacd0405f3c1bb874 commit 7d53105d6ed984aec255fa0eacd0405f3c1bb874 Author: Nick Alcock Date: Mon Sep 27 20:31:21 2021 +0100 libctf: link against libiberty before linking in libbfd or libctf-nobfd This ensures that the CTF_LIBADD, which always contains at least this when doing a shared link: -L`pwd`/../libiberty/pic -liberty appears in the link line before any requirements pulled in by libbfd.la, which include -liberty but because it is install-time do not include the -L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path comes from the libbfd.la file, and is an install path). libiberty also appears after libbfd in the link line by virtue of libctf-nobfd.la, because libctf-nobfd has to follow libbfd in the link line, and that needs symbols from libiberty too. Without this, an installed liberty might well be pulled in by libbfd, and if --enable-install-libiberty is not specified this libiberty might be completely incompatible with what is being installed and break either or boht of libbfd and libctf. (The specific problem observed here is that bsearch_r was not present, but other problems might easily be observed in future too.) Because ld links against libctf, this has a tendency to break the system linker at install time too, if installing with --prefix=/usr. That's quite unpleasant to recover from. libctf/ChangeLog 2021-09-27 Nick Alcock PR libctf/27360 * Makefile.am (libctf_la_LIBADD): Link against libiberty before pulling in libbfd.la or pulling in libctf-nobfd.la. * Makefile.in: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bc4b1401129c755eb78d434ae88605478f4299f1 commit bc4b1401129c755eb78d434ae88605478f4299f1 Author: Nick Alcock Date: Mon Sep 27 20:31:21 2021 +0100 libtool.m4: augment symcode for Solaris 11 This reports common symbols like GNU nm, via a type code of 'C'. ChangeLog 2021-09-27 Nick Alcock PR libctf/27967 * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ea9c2009115d7e00732f5ad316c10a171fc66a53 commit ea9c2009115d7e00732f5ad316c10a171fc66a53 Author: Nick Alcock Date: Mon Sep 27 20:31:21 2021 +0100 libctf: try several possibilities for linker versioning flags Checking for linker versioning by just grepping ld --help output for mentions of --version-script is inadequate now that Solaris 11.4 implements a --version-script with different semantics. Try linking a test program with a small wildcard-using version script with each supported set of flags in turn, to make sure that linker versioning is not only advertised but actually works. The Solaris "GNU-compatible" linker versioning is not quite GNU-compatible enough, but we can work around the differences by generating a new version script that removes the comments from the original (Solaris ld requires #-style comments), and making another version script for libctf-nonbfd in particular which doesn't mention any of the symbols that appear in libctf.la, to avoid Solaris ld introducing corresponding new NOTYPE symbols to match the version script. libctf/ChangeLog 2021-09-27 Nick Alcock PR libctf/27967 * configure.ac (VERSION_FLAGS): Replace with... (ac_cv_libctf_version_script): ... this multiple test. (VERSION_FLAGS_NOBFD): Substitute this too. * Makefile.am (libctf_nobfd_la_LDFLAGS): Use it. Split out... (libctf_ldflags_nover): ... non-versioning flags here. (libctf_la_LDFLAGS): Use it. * libctf.ver: Give every symbol not in libctf-nobfd a comment on the same line noting as much. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bef9ef8ca0f941d743c77cc55b5fe7985990b2a7 commit bef9ef8ca0f941d743c77cc55b5fe7985990b2a7 Author: Nick Alcock Date: Mon Sep 27 20:31:21 2021 +0100 libtool.m4: fix nm BSD flag detection Libtool needs to get BSD-format (or MS-format) output out of the system nm, so that it can scan generated object files for symbol names for -export-symbols-regex support. Some nms need specific flags to turn on BSD-formatted output, so libtool checks for this in its AC_PATH_NM. Unfortunately the code to do this has a pair of interlocking flaws: - it runs the test by doing an nm of /dev/null. Some platforms reasonably refuse to do an nm on a device file, but before now this has only been worked around by assuming that the error message has a specific textual form emitted by Tru64 nm, and that getting this error means this is Tru64 nm and that nm -B would work to produce BSD-format output, even though the test never actually got anything but an error message out of nm -B. This is fixable by nm'ing *nm itself* (since we necessarily have a path to it). - the test is entirely skipped if NM is set in the environment, on the grounds that the user has overridden the test: but the user cannot reasonably be expected to know that libtool wants not only nm but also flags forcing BSD-format output. Worse yet, one such "user" is the top-level Cygnus configure script, which neither tests for nor specifies any BSD-format flags. So platforms needing BSD-format flags always fail to set them when run in a Cygnus tree, breaking -export-symbols-regex on such platforms. Libtool also needs to augment $LD on some platforms, but this is done unconditionally, augmenting whatever the user specified: the nm check should do the same. One wrinkle: if the user has overridden $NM, a path might have been provided: so we use the user-specified path if there was one, and otherwise do the path search as usual. (If the nm specified doesn't work, this might lead to a few extra pointless path searches -- but the test is going to fail anyway, so that's not a problem.) (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.) ChangeLog 2021-09-27 Nick Alcock PR libctf/27967 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid errors from nms that refuse to work on non-regular files. Remove other workarounds for this problem. Strip out blank lines from the nm output. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28391] New: strip/objcopy --preserve-dates *.a: cannot set time: Invalid argument
https://sourceware.org/bugzilla/show_bug.cgi?id=28391
Bug ID: 28391
Summary: strip/objcopy --preserve-dates *.a: cannot set time:
Invalid argument
Product: binutils
Version: 2.38 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: glebfm at altlinux dot org
Target Milestone: ---
$ gcc -c -xc /dev/null -o t.o
$ ar rcsU t.a t.o
$ strace --failed-only -e /time strip -p t.a
utimensat(AT_FDCWD, "steICERy/t.o", [{tv_sec=140428413401793, tv_nsec=48} /*
4451969-04-09T19:36:33.00048+ */, {tv_sec=1632773474,
tv_nsec=94919810130032}], 0) = -1 EINVAL (Invalid argument)
strip: steICERy/t.o: cannot set time: Invalid argument
+++ exited with 0 +++
$ strace --failed-only -e /time objcopy -p t.a t1.a
utimensat(AT_FDCWD, "stk5ToKP/t.o", [{tv_sec=640, tv_nsec=48} /*
1970-01-01T00:10:40.00048+ */, {tv_sec=0, tv_nsec=223338299408}], 0) =
-1 EINVAL (Invalid argument)
objcopy: stk5ToKP/t.o: cannot set time: Invalid argument
+++ exited with 0 +++
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/21472] [avr] Add new emulation for ATtiny416 et al.
https://sourceware.org/bugzilla/show_bug.cgi?id=21472 Roman Jay Almaza changed: What|Removed |Added CC||dianeBerlusconi at gmail dot com --- Comment #7 from Roman Jay Almaza --- Has this bug solved already? https://www.congdonandcoleman.com/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28381] abort in intel_operand_size
https://sourceware.org/bugzilla/show_bug.cgi?id=28381
--- Comment #4 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Lili Cui :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2c02075a8ec5223bc4cbcc9561eb91e28d46a9e5
commit 2c02075a8ec5223bc4cbcc9561eb91e28d46a9e5
Author: Cui,Lili
Date: Tue Sep 28 11:13:33 2021 +0800
x86: Print {bad} on invalid broadcast in OP_E_memory
Don't print broadcast for scalar_mode, and print {bad} for invalid
broadcast.
gas/
PR binutils/28381
* testsuite/gas/i386/bad-bcast.s: Add a new testcase.
* testsuite/gas/i386/bad-bcast.d: Likewise.
* testsuite/gas/i386/bad-bcast-intel.d: New.
opcodes/
PR binutils/28381
* i386-dis.c (static struct): Add no_broadcast.
(OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print
"{bad}"for it.
(intel_operand_size): mark invalid broadcast with no_broadcast=1.
(OP_XMM): Mark scalar_mode with no_broadcast=1.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28381] abort in intel_operand_size
https://sourceware.org/bugzilla/show_bug.cgi?id=28381 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from H.J. Lu --- Fixed for 2.38. -- You are receiving this mail because: You are on the CC list for the bug.
