[Bug ld/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym
https://sourceware.org/bugzilla/show_bug.cgi?id=22832 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Eric Botcazou --- > Thus, when linking one of these object files, that object file's hash table > never pulls in the definition of __tls_get_addr, and so when > _bfd_sparc_elf_check_relocs is called for an R_SPARC_TLS_LDM_CALL, it looks > up __tls_get_addr, doesn't find it, and so an entry is created, since TRUE > is passed to bfd_link_hash_lookup for create, but this entry has type > bfd_link_hash_new, and this never changes. > > So it seems to me there are two issues here: > > 1. LLVM should be emitting an entry for __tls_get_addr in its symbol table > so it is made visible to the object file. > > 2. ld should gracefully handle this case. If this case is an error, it > should instead be passing FALSE for create to bfd_link_hash_lookup, and if > the result is NULL, printing an error; otherwise, if this case should work, > something needs to implicitly pull in the symbol (and in theory LLVM doesn't > need to change, though in practice it's best to do so anyway for > compatibility). Thanks for debugging this. The irony is that I put TRUE precisely because I thought it would deal with such a case... Given that Gold and ld agree, I think that the error is indeed on the LLVM side but you're right that ld should handle this more gracefully (it's not too bad either). Do you want me to prepare a patch or do you intend to do it? -- 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/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym
https://sourceware.org/bugzilla/show_bug.cgi?id=22832
--- Comment #4 from James Clarke ---
So, after debugging this, the problem is as follows:
Rust is using LLVM with -integrated-as (at least effectively; it may well be
using it as a library and setting the flag itself, but the point is that the
lowered IR is fed straight into the object code backend rather than being
serialised via assembly and then assembled separately). LLVM's
SparcMCCodeEmitter::getCallTargetOpValue handles __tls_get_addr specially to
not emit an R_SPARC_WDISP30/WPLT30, and somewhere else the R_SPARC_TLS_LDM_CALL
gets emitted, but the important point is that __tls_get_addr is never added to
the output object file's symbol table despite being the symbolic operand to the
call instruction.
Thus, when linking one of these object files, that object file's hash table
never pulls in the definition of __tls_get_addr, and so when
_bfd_sparc_elf_check_relocs is called for an R_SPARC_TLS_LDM_CALL, it looks up
__tls_get_addr, doesn't find it, and so an entry is created, since TRUE is
passed to bfd_link_hash_lookup for create, but this entry has type
bfd_link_hash_new, and this never changes.
So it seems to me there are two issues here:
1. LLVM should be emitting an entry for __tls_get_addr in its symbol table so
it is made visible to the object file.
2. ld should gracefully handle this case. If this case is an error, it should
instead be passing FALSE for create to bfd_link_hash_lookup, and if the result
is NULL, printing an error; otherwise, if this case should work, something
needs to implicitly pull in the symbol (and in theory LLVM doesn't need to
change, though in practice it's best to do so anyway for compatibility).
I've talked specifically about local-dynamic here for simplicity, but
global-dynamic has the same issue too.
Note that gold also falls foul of this, giving "gold: internal error in
tls_get_addr_sym, at ../../gold/sparc.cc:391", though line 391 is
"gold_assert(this->tls_get_addr_sym_);" which is much easier to debug!
Reproduction:
jrtc27@deb4g:~/tmp/22832$ cat 22832.c
__thread int x;
int f(void) { return x; }
jrtc27@deb4g:~/tmp/22832$ clang -integrated-as -o 22832.o -fPIC -c 22832.c
jrtc27@deb4g:~/tmp/22832$ readelf -Wrs 22832.o
Relocation section '.rela.text' at offset 0x138 contains 6 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0008 00030011 R_SPARC_PC22
_GLOBAL_OFFSET_TABLE_ + 4
000c 00030010 R_SPARC_PC10
_GLOBAL_OFFSET_TABLE_ + 8
0014 00050038 R_SPARC_TLS_GD_HI22 x +
0
0018 00050039 R_SPARC_TLS_GD_LO10 x +
0
001c 0005003a R_SPARC_TLS_GD_ADD x +
0
0020 0005003b R_SPARC_TLS_GD_CALL x +
0
Symbol table '.symtab' contains 6 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS 22832.c
2: 0 TLS LOCAL DEFAULT4 .tbss
3: 0 NOTYPE GLOBAL DEFAULT UND
_GLOBAL_OFFSET_TABLE_
4: 52 FUNCGLOBAL DEFAULT2 f
5: 4 TLS GLOBAL DEFAULT4 x
jrtc27@deb4g:~/tmp/22832$ ld -o lib22832.so -shared 22832.o
ld: BFD (GNU Binutils) 2.30.51.20180211 internal error, aborting at
elflink.c:9710 in elf_link_output_extsym
ld: Please report this bug.
jrtc27@deb4g:~/tmp/22832$ gold -o lib22832.so -shared 22832.o
gold: internal error in tls_get_addr_sym, at ../../gold/sparc.cc:391
--
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/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #17 from H.J. Lu --- Please try users/hjl/solaris branch at https://github.com/hjl-tools/binutils-gdb -- 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/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from H.J. Lu --- [hjl@gnu-6 solaris-1]$ cat dummy.s .text .global _start _start: movlfoo@indntpoff, %eax .globl bar .type bar, @function bar: lealfoo@tlsgd(,%ebx,1), %eax call___tls_get_addr@PLT movl(%eax), %eax .globl foo .section.tbss,"awT",@nobits .align 4 .type foo, @object .size foo, 4 foo: .zero 4 [hjl@gnu-6 solaris-1]$ gcc -c -m32 dummy.s [hjl@gnu-6 solaris-1]$ ./ld -m elf_i386_sol2 dummy.o ./ld: BFD (GNU Binutils) 2.30.51.20180212 internal error, aborting at /export/gnu/import/git/sources/binutils-gdb/bfd/elf32-i386.c:3169 in elf_i386_relocate_section ./ld: Please report this bug. [hjl@gnu-6 solaris-1]$ ld -m elf_i386 dummy.o [hjl@gnu-6 solaris-1]$ -- 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/22829] objcopy/strip: PT_GNU_RELRO is removed when it's not placed before read-only section
https://sourceware.org/bugzilla/show_bug.cgi?id=22829 --- Comment #9 from NGG --- The second patch works in all the cases I've tried, thanks! -- 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/22840] New: Several TLS tests FAIL on Solaris/SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22840 Bug ID: 22840 Summary: Several TLS tests FAIL on Solaris/SPARC Product: binutils Version: 2.31 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Several of the ld TLS tests FAIL on Solaris/SPARC (both in a sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11 configuration): FAIL: 32-bit: TLS -fpic -shared transitions FAIL: 32-bit: TLS -fpic and -fno-pic exec transitions FAIL: 32-bit: TLS -fno-pic -shared FAIL: 32-bit: TLS -fpie FAIL: 32-bit: GOTDATA relocations FAIL: relaxed call WDISP30 relocation FAIL: 64-bit: TLS -fpic -shared transitions FAIL: 64-bit: TLS -fpic and -fno-pic exec transitions FAIL: 64-bit: TLS -fno-pic -shared FAIL: 64-bit: TLS -fpie FAIL: 64-bit: GOTDATA relocations There are several issues here: * Initially, the failures are like /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: target elf32-sparc not found /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: target elf32-sparc not found or the elf64-sparc equivalent. This happens because sparc.exp hardcodes -melf32_sparc resp. -melf64_sparc, while Solaris uses (and requires) the -melf32_sparc_sol2 resp. -melf64_sparc_sol2 emulations. Unfortunately, unlike the #ld: lines in the *.?d files which can be modified by setting options_regsub(ld) for perform the appropriate substitution, this is not currently possible for the arg to run_ld_link_tests. * To make some progress, I've hardcoded the Solaris values for now, which leads me to the next issues: The file format lines in the *.?d files under test all hardcode elf32-sparc or elf64-sparc, but should allow for elf32-sparc-sol2 (resp. elf32-sparc.*). * Even with that fixed, there are many failures due to the fact that the Solaris ABI requires a couple of additional symbols (cf. emultempl/solaris2.em (elf_solaris2_before_allocation), and those aren't currently expected in the output. I'm uncertain how best to handle that: allow for a postprocessing step after readelf that removes those from the output or augment the expected output accordingly? It seems regexp_diff currently has no support for optional or target-specific lines in the expected output. Rainer -- 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/22839] New: Several plugin tests FAIL on 32-bit Solaris/SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22839 Bug ID: 22839 Summary: Several plugin tests FAIL on 32-bit Solaris/SPARC Product: binutils Version: 2.31 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 When running make check on 32-bit Solaris/SPARC, a couple of plugin tests FAIL: FAIL: load plugin with source FAIL: plugin claimfile lost symbol with source FAIL: plugin claimfile replace symbol with source FAIL: plugin claimfile resolve symbol with source FAIL: plugin claimfile replace file with source FAIL: plugin set symbol visibility with source FAIL: plugin ignore lib with source FAIL: plugin claimfile replace lib with source FAIL: plugin 2 with source lib FAIL: load plugin 2 with source FAIL: load plugin 2 with source and -r FAIL: plugin 3 with source lib FAIL: load plugin 3 with source FAIL: load plugin 3 with source and -r FAIL: PR ld/20070 It's always the same pattern, it seems (for the first one here): Hello from testplugin. tv[0]: LDPT_MESSAGE func@0x1363fc tv[1]: LDPT_API_VERSION value0x1 (1) tv[2]: LDPT_GNU_LD_VERSION value 0xe6 (230) tv[3]: LDPT_LINKER_OUTPUT value0x1 (1) tv[4]: LDPT_OUTPUT_NAME 'tmpdir/main.x' tv[5]: LDPT_REGISTER_CLAIM_FILE_HOOK func@0x135d88 tv[6]: LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK func@0x135d48 tv[7]: LDPT_REGISTER_CLEANUP_HOOK func@0x135d08 tv[8]: LDPT_ADD_SYMBOLS func@0x1360c4 tv[9]: LDPT_GET_INPUT_FILE func@0x135c9c tv[10]: LDPT_GET_VIEW func@0x135ef4 tv[11]: LDPT_RELEASE_INPUT_FILE func@0x135c48 tv[12]: LDPT_GET_SYMBOLS func@0x1368d8 tv[13]: LDPT_GET_SYMBOLS_V2 func@0x1368cc tv[14]: LDPT_ADD_INPUT_FILE func@0x135e8c tv[15]: LDPT_ADD_INPUT_LIBRARY func@0x135e24 tv[16]: LDPT_SET_EXTRA_LIBRARY_PATH func@0x135dc8 tv[17]: LDPT_OPTION 'registerclaimfile' tv[18]: LDPT_OPTION 'claim:/vol/src/gnu/binutils/binutils/local/ld/testsuite/ld-plugin/func.c' tv[19]: LDPT_NULL value0x0 (0) hook called: claim_file tmpdir/main.o [@0/3100] not claimed hook called: claim_file /vol/src/gnu/binutils/binutils/local/ld/testsuite/ld-plugin/func.c [@0/248] CLAIMED /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: BFD (GNU Binutils) 2.30.51.20180209 internal error, aborting at /vol/src/gnu/binutils/binutils/local/bfd/elf32-sparc.c:155 in elf32_sparc_final_write_processing /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: Please report this bug. At this point, for some reason we have: arch = bfd_arch_unknown, mach = 0, arch_name = 0xef2e0 "unknown", However, when mach is first set, it looks perfectly reasonable: bfd_default_set_arch_mach (abfd=0x21a578, arch=bfd_arch_sparc, mach=1) The same tests all PASS on sparcv9-sun-solaris2.11, btw. Rainer -- 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 gold/22838] Incorrect linking for try-catch statement for target MIPS32 R2 little endian.
https://sourceware.org/bugzilla/show_bug.cgi?id=22838 Ilija Pavlovic changed: What|Removed |Added CC||Ilija.Pavlovic at mips 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 gold/22838] New: Incorrect linking for try-catch statement for target MIPS32 R2 little endian.
https://sourceware.org/bugzilla/show_bug.cgi?id=22838
Bug ID: 22838
Summary: Incorrect linking for try-catch statement for target
MIPS32 R2 little endian.
Product: binutils
Version: 2.28
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: Ilija.Pavlovic at mips dot com
CC: ian at airs dot com
Target Milestone: ---
Created attachment 10812
--> https://sourceware.org/bugzilla/attachment.cgi?id=10812=edit
Files and the script for reproducing the problem.
Consider following example:
int main(int argc, char* argv[]) {
try {
throw 20;
} catch (...) {
return 123;
}
return 0;
}
The catch block should capture any kind of exceptions.
If this example is linked with gold linker for target MIPS32 R2 little endian,
execution of the example will result with error message "Segmentation fault".
If the same example is linked without -pie flag (Create a position independent
executable), the example will be linked correctly and executed as it is
expected.
This is tested with the Clang version 6.0.0 (trunk 321529) and the gold linker
version 2.28 (GNU gold (GNU Binutils 2.28) 1.14).
All files, parameters and commands needed for reproducing the problem are in
the attached file.
--
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/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #15 from Rainer Orth --- > --- Comment #14 from H.J. Lu --- [...] > Please provide all linker inputs so that I > can reproduce i it on Linux. Now available at https://www.cebitec.uni-bielefeld.de/~ro/files/pr13671.tar.bz2 -- 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/22836] "-r -s" doesn't work with -g3 using GCC 7
https://sourceware.org/bugzilla/show_bug.cgi?id=22836 --- Comment #1 from H.J. Lu --- "strip -g" works correctly. -- 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/22836] New: "-r -s" doesn't work with -g3 using GCC 7
https://sourceware.org/bugzilla/show_bug.cgi?id=22836
Bug ID: 22836
Summary: "-r -s" doesn't work with -g3 using GCC 7
Product: binutils
Version: 2.31 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-4 tmp]$ cat x.c
void
foo ()
{
}
[hjl@gnu-4 tmp]$ gcc -c -g3 x.c
[hjl@gnu-4 tmp]$ ld.bfd -r -s x.o
ld.bfd: BFD (Linux/GNU Binutils) 2.30.51.0.1.20180210 assertion fail
/net/gnu-bdx-1/export/linux/src/binutils/binutils/bfd/elf.c:3565
ld.bfd: BFD (Linux/GNU Binutils) 2.30.51.0.1.20180210 assertion fail
/net/gnu-bdx-1/export/linux/src/binutils/binutils/bfd/elf.c:3565
Gold gives reason, but still fails:
[hjl@gnu-4 tmp]$ ld.gold -r -s x.o
ld.gold: error: x.o: section group retained but group element discarded
ld.gold: error: x.o: section group retained but group element discarded
ld.gold: error: x.o: section group retained but group element discarded
ld.gold: error: x.o: section group retained but group element discarded
[hjl@gnu-4 tmp]$
--
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/22829] objcopy/strip: PT_GNU_RELRO is removed when it's not placed before read-only section
https://sourceware.org/bugzilla/show_bug.cgi?id=22829 Alan Modra changed: What|Removed |Added Attachment #10808|0 |1 is obsolete|| --- Comment #8 from Alan Modra --- Created attachment 10810 --> https://sourceware.org/bugzilla/attachment.cgi?id=10810=edit a better fix -- 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/22829] objcopy/strip: PT_GNU_RELRO is removed when it's not placed before read-only section
https://sourceware.org/bugzilla/show_bug.cgi?id=22829 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gmail dot com| Assignee|unassigned at sourceware dot org |amodra at gmail dot com Severity|enhancement |normal -- 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/22823] bfd/libbfd.h:268:4: error: cast between incompatible function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(st
https://sourceware.org/bugzilla/show_bug.cgi?id=22823
--- Comment #3 from dilyan.palauzov at aegee dot org ---
This shifts the errors few lines further:
make[4]: Entering directory '/home/d/binutils/bfd'
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/git/binutils-gdb/bfd -I. -I/git/binutils-gdb/bfd
-I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR='"/usr/local/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c -o binary.lo /git/binutils-gdb/bfd/binary.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/bfd -I.
-I/git/binutils-gdb/bfd -I/git/binutils-gdb/bfd/../include -DHAVE_all_vecs
-DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror -O3 -pipe -MT binary.lo -MD -MP -MF
.deps/binary.Tpo -c /git/binutils-gdb/bfd/binary.c -o binary.o
In file included from /git/binutils-gdb/bfd/binary.c:38:
/git/binutils-gdb/bfd/libbfd.h:305:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, char **, bfd_size_type *, const char **)’ {aka ‘int
(*)(struct bfd *, char **, long unsigned int *, const char **)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, char **, bfd_size_type *, const char **)) \
^
./bfd.h:7519:3: note: in expansion of macro
‘_bfd_noarchive_construct_extended_name_table’
NAME##_construct_extended_name_table, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:308:4: error: cast between incompatible function
types from ‘void (*)(bfd *)’ {aka ‘void (*)(struct bfd *)’} to ‘void (*)(bfd *,
const char *, char *)’ {aka ‘void (*)(struct bfd *, const char *, char *)’}
[-Werror=cast-function-type]
((void (*) (bfd *, const char *, char *)) bfd_void)
^
./bfd.h:7520:3: note: in expansion of macro ‘_bfd_noarchive_truncate_arname’
NAME##_truncate_arname, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:310:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, unsigned int, struct orl *, unsigned int, int)’ {aka
‘int (*)(struct bfd *, unsigned int, struct orl *, unsigned int, int)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, unsigned int, struct orl *, unsigned int, int)) \
^
./bfd.h:7521:3: note: in expansion of macro ‘_bfd_noarchive_write_armap’
NAME##_write_armap, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:314:4: error: cast between incompatible function
types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to
‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd_boolean (*) (bfd *, bfd *)) bfd_false)
^
./bfd.h:7523:3: note: in expansion of macro ‘_bfd_noarchive_write_ar_hdr’
NAME##_write_ar_hdr, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:316:4: error: cast between incompatible function
types from ‘void * (*)(bfd *)’ {aka ‘void * (*)(struct bfd *)’} to ‘bfd *
(*)(bfd *, bfd *)’ {aka ‘struct bfd * (*)(struct bfd *, struct bfd *)’}
[-Werror=cast-function-type]
((bfd *(*) (bfd *, bfd *)) bfd_nullvoidptr)
^
./bfd.h:7524:3: note: in expansion of macro
‘_bfd_noarchive_openr_next_archived_file’
NAME##_openr_next_archived_file, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:318:4: error: cast between incompatible function
types from ‘void * (*)(bfd *)’ {aka ‘void * (*)(struct bfd *)’} to ‘bfd *
(*)(bfd *, symindex)’ {aka ‘struct bfd * (*)(struct bfd *, long unsigned int)’}
[-Werror=cast-function-type]
((bfd *(*) (bfd *, symindex)) bfd_nullvoidptr)
^
./bfd.h:7525:3: note: in expansion of macro ‘_bfd_noarchive_get_elt_at_index’
NAME##_get_elt_at_index, \
^~~~
/git/binutils-gdb/bfd/binary.c:364:3: note: in expansion of macro
‘BFD_JUMP_TABLE_ARCHIVE’
BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
^~
/git/binutils-gdb/bfd/libbfd.h:417:4: error: cast between incompatible function
types from ‘void (*)(bfd *)’ {aka ‘void (*)(struct bfd *)’} to ‘void (*)(bfd *,
void *, asymbol *, bfd_print_symbol_type)’ {aka ‘void
[Bug gas/22835] New: The unused rs_broken_word in enum _relax_state
https://sourceware.org/bugzilla/show_bug.cgi?id=22835 Bug ID: 22835 Summary: The unused rs_broken_word in enum _relax_state Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- enum _relax_state in as.h has #ifndef WORKING_DOT_WORD /* JF: gunpoint */ rs_broken_word, #endif Since WORKING_DOT_WORD is defined later, we leave the unused rs_broken_word in as.h -- 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/22823] bfd/libbfd.h:268:4: error: cast between incompatible function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(st
https://sourceware.org/bugzilla/show_bug.cgi?id=22823 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 10809 --> https://sourceware.org/bugzilla/attachment.cgi?id=10809=edit Proposed patch Hi Dilyan, Would you mind trying out this patch and let me know if it works ? I do not have access to a gcc-8 build system at the moment, so I am not sure if this fix will actually make things any better... 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
Re: bfd/elf32-arc.c:1537]: (warning) Redundant assignment
Hi David, > bfd/elf32-arc.c:1537]: (warning) Redundant assignment of 'rel->r_offset' to > itself. Thanks for reporting this problem. I have checked in a small patch to remove the assignment. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: bfd/elf32-nds32.c:9693]: (warning) Redundant assignment
Hi David, > bfd/elf32-nds32.c:9693]: (warning) Redundant assignment of 'irel->r_addend' > to itself. Thanks for reporting this. I have checked in the obvious fix of removing the redundant assignment. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
