[Bug binutils/25351] .ARM.attributes not found
https://sourceware.org/bugzilla/show_bug.cgi?id=25351 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-08 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] New: nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Bug ID: 25355 Summary: nm reports a variable as "T" with -flto and -fno-common Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- As being discussed here: https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html nm reports misleadingly a global variable: $ cat nm.c char nm_test_var; $ gcc-9 nm.c -c -fno-common $ nm nm.o B nm_test_var $ gcc-9 nm.c -c -fno-common -flto $ nm nm.o T nm_test_var So the issue is that I would expect "B" from the last nm invocation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25351] .ARM.attributes not found
https://sourceware.org/bugzilla/show_bug.cgi?id=25351 --- 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=4c6ee6465acc58f0f86c44668c4e862901186239 commit 4c6ee6465acc58f0f86c44668c4e862901186239 Author: Alan Modra Date: Wed Jan 8 11:36:01 2020 +1030 PR25351 .ARM.attributes not found for symbol PR 25351 * elflink.c (bfd_elf_final_link): Call _bfd_fix_excluded_sec_syms after removing sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
Hi Martin,
I think that this problem is due to a weakness in the plugin-api. The
specification of the ld_plugin_symbol_kind enum only has five values:
enum ld_plugin_symbol_kind
{
LDPK_DEF,
LDPK_WEAKDEF,
LDPK_UNDEF,
LDPK_WEAKUNDEF,
LDPK_COMMON
};
So it does not have a way to distinguish between code symbols and data symbols.
Hence when a defined symbol is seen the BFD library has to make a choice, and
it chooses to assume that it is a code symbol. Given that section names have
also been discarded by this point, it is impossible for the library to
distinguish between code and data symbols.
So unless we create a new version of the plugin API, I think that this will
have to remain as an unsolved problem. At least that is my take on the
subject. Lets see if anyone else has any better ideas.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25331] mmix-gas fails to assemble newlib-3.1.0: internal error: fixup not contained within frag
https://sourceware.org/bugzilla/show_bug.cgi?id=25331 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- If it helps, assembling with --no-expand works. Not sure if this is sufficient for a workaround however, since I am unfamiliar with the MMIX instruction set. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca --- Comment #2 from Nick Bowler --- Summary of the issue in libtool: libtool needs to produce C declarations for arbitrary symbols based on nm output, in order to implement various features such as dlpreopen which depend on putting symbol values into C data structures. Some linkers (apparently this the case on HP-UX) are strict and won't let function declarations refer to variables and vice versa. So the nm symbol type is used to produce either a function or variable declaration, as appropriate. Unfortunately, with LTO enabled the GNU linker (or does GCC do everything in this case?) seems to also have this restriction: it is an error for a function declaration to refer to a variable or vice versa. So libtool uses the symbol type reported by nm to produce function declarations for functions, and variable declarations for variables. Unfortunately, with LTO enabled then GNU nm does not distinguish between functions and variables (however, clang and llvm-nm seems to be fine in this regard). There is no obvious way to work around the LTO function/data declaration issue in C code. It seems libtool has to know, in advance, whether any given symbol is code or data in order to produce a declaration that will link successfully. I see several options that would work to resolve the libtool problem: - Fix GNU nm to report functions and variables differently (best). - Fix GNU ld (or GCC?) so that it is not a hard error to refer to variables with function declarations or vice versa, so the nm issue does not matter. - Figure out another way to get the value of a symbol in C code without knowing anything other than its name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/14891] Section name and symbol name clash
https://sourceware.org/bugzilla/show_bug.cgi?id=14891 --- Comment #3 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=f1f28025c3ea75d5368ddd3046461648145b89b3 commit f1f28025c3ea75d5368ddd3046461648145b89b3 Author: Nick Clifton Date: Wed Jan 8 16:30:20 2020 + Make the assembler generate an error if there is an attempt to define a section with the same name as an already defined symbol. PR 14891 * config/obj-elf.c (obj_elf_section): Fail if the section name is already defined as a different symbol type. * testsuite/gas/elf/pr14891.s: New test source file. * testsuite/gas/elf/pr14891.d: New test driver. * testsuite/gas/elf/pr14891.s: New test expected error output. * testsuite/gas/elf/elf.exp: Run the new test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/14891] Section name and symbol name clash
https://sourceware.org/bugzilla/show_bug.cgi?id=14891 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- I have checked in a patch that fixes the test case using .section. There may however be other ways of triggering a name conflict that I have not considered. If so then this PR can be reopened. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 18675 in oss-fuzz: binutils:fuzz_disassemble: Direct-leak in create_register_operand_with_size
Updates: Labels: -restrict-view-commit Comment #4 on issue 18675 by sheriff...@chromium.org: binutils:fuzz_disassemble: Direct-leak in create_register_operand_with_size https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18675#c4 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 ld/25285] FAIL: Run with libfunc1.so comm1.o with GCC 10
https://sourceware.org/bugzilla/show_bug.cgi?id=25285 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Andrew Pinski from comment #0) Hi Andrew, > /bajas/pinskia/src/toolchain-10/marvell-tools/bin/../lib/gcc/aarch64-marvell- > linux-gnu/10.0.0/../../../../aarch64-marvell-linux-gnu/bin/ld: warning: type > of symbol `foo' changed from 2 to 1 in tmpdir/comm1.o I think that this issue may have been fixed by my patch for PR25327. Please could you check and let me know ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25284] Disallow .align .p2align .balign without operands
https://sourceware.org/bugzilla/show_bug.cgi?id=25284 --- Comment #1 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=915808f652b63746052b1ef59403650b45a30e4f commit 915808f652b63746052b1ef59403650b45a30e4f Author: Nick Clifton Date: Wed Jan 8 17:00:54 2020 + Document the fact that the assembler's alignment pseudo-ops can be issued without any argumemtns. PR 25284 * doc/as.texi (Align): Document the fact that all arguments can be omitted. (Balign): Likewise. (P2align): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25284] Disallow .align .p2align .balign without operands
https://sourceware.org/bugzilla/show_bug.cgi?id=25284 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Ray, I prefer not to change the assembler's behaviour in a situation like this, so instead I have documented what happens. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25224] [Z80][PATCH] Add support for Zilog Z180 and eZ80 CPUs
https://sourceware.org/bugzilla/show_bug.cgi?id=25224 Luis Machado changed: What|Removed |Added CC||luis.machado at linaro dot org --- Comment #20 from Luis Machado --- This seems to be causing build errors for GDB on aarch64 (and possibly other archs, maybe s390 as well) on the buildbots. gcc -DHAVE_CONFIG_H -I. -I../../binutils-gdb/opcodes -I. -I../../binutils-gdb/opcodes -I../bfd -I../../binutils-gdb/opcodes/../include -I../../binutils-gdb/opcodes/../bfd -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -g -D_GLIBCXX_DEBUG -MT z8k-dis.lo -MD -MP -MF .deps/z8k-dis.Tpo -c ../../binutils-gdb/opcodes/z8k-dis.c -o z8k-dis.o ../../binutils-gdb/opcodes/z80-dis.c: In function 'ld_ii_ii': ../../binutils-gdb/opcodes/z80-dis.c:606:36: error: comparison is always false due to limited range of data type [-Werror=type-limits] p = (buf->data[buf->n_fetch - 2] == '\xdd') ? 0 : 1; GDB builds with Werror, so this warning will trigger a build failure. Could you please take a look at it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25224] [Z80][PATCH] Add support for Zilog Z180 and eZ80 CPUs
https://sourceware.org/bugzilla/show_bug.cgi?id=25224 --- Comment #21 from Luis Machado --- For the record, here's the complete build log: https://gdb-buildbot.osci.io/#/builders/8/builds/1618/steps/7/logs/stdio -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25224] [Z80][PATCH] Add support for Zilog Z180 and eZ80 CPUs
https://sourceware.org/bugzilla/show_bug.cgi?id=25224 Luis Machado changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #22 from Luis Machado --- Reopened since it is causing a warning that fails to build with Werror. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25356] New: nm reports wrong symbol types on lto objects (using linker plugin)
https://sourceware.org/bugzilla/show_bug.cgi?id=25356 Bug ID: 25356 Summary: nm reports wrong symbol types on lto objects (using linker plugin) Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: calvin.walton at kepstin dot ca Target Milestone: --- Using the following example C file: int foo; int bar = 0; And compiling the file normally, with gcc -c -o test.o test.c, the nm output looks like this: B bar 0004 C foo And with gcc -fno-common -c -o test.o test.c: 0004 B bar B foo But when compiling with lto, and using the linker plugin with nm, it returns incorrect symbol types: With gcc -flto -c -o test.o test.c: T bar C foo With gcc -flto -fno-common -c -o test.o test.c: T bar T foo In both cases, it's reporting the symbols as being in the text (code) section. This behaviour confuses the libtool configure-time check used by the global_symbol_pipe feature (causing linking errors when compiling packages that use the libtool -export-symbols-regex feature in combination with gcc -flto, particularly when also using -fno-common) Link to thread about the libtool issue: https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html I'm guessing that this is probably due to a limitation of how nm is using the linker plugin interface? The symbols that the plugin reports using the ld_plugin_add_symbols linker interface method don't include section information. I'm currently using: gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU nm version 2.32-30.fc31 Copyright (C) 2019 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25356] nm reports wrong symbol types on lto objects (using linker plugin)
https://sourceware.org/bugzilla/show_bug.cgi?id=25356 Calvin Walton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Calvin Walton --- Oops, missed that this had already been filed. *** This bug has been marked as a duplicate of bug 25355 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Calvin Walton changed: What|Removed |Added CC||calvin.walton at kepstin dot ca --- Comment #3 from Calvin Walton --- *** Bug 25356 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/25327] FAIL: Run pr20276
https://sourceware.org/bugzilla/show_bug.cgi?id=25327 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- *** Bug 25285 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/25285] FAIL: Run with libfunc1.so comm1.o with GCC 10
https://sourceware.org/bugzilla/show_bug.cgi?id=25285 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- (In reply to Nick Clifton from comment #1) > > I think that this issue may have been fixed by my patch for PR25327. Please > could you check and let me know ? Yes they are fixed. *** This bug has been marked as a duplicate of bug 25327 *** -- You are receiving this mail because: You are on the CC list for the bug.
