https://sourceware.org/bugzilla/show_bug.cgi?id=29389
--- Comment #7 from Luca Bacci <luca.bacci at outlook dot com> ---
Thanks, Alan!
I'm going to make a bundle containing all the required object files, will
attach it very soon.
Right now I have just tried debugging this issue in GDB a bit. What I could
find is that when the warning "local symbol `0' has no section" is output by
coff_classify_symbol (bfd *abfd, struct internal_syment *syment), syment points
to freed memory:
Thread 1 hit Breakpoint 1, coff_classify_symbol (abfd=0x1a32e152710,
syment=0x23121ff2f0) at ../../binutils-gdb/bfd/coffcode.h:5038
5038 _bfd_error_handler
(gdb) bt
#0 coff_classify_symbol (abfd=0x1a32e152710, syment=0x23121ff2f0)
at ../../binutils-gdb/bfd/coffcode.h:5038
#1 0x00007ff6eda466a6 in _bfd_coff_link_input_bfd (flaginfo=0x23121ff700,
input_bfd=0x1a32e152710) at ../../binutils-gdb/bfd/cofflink.c:1446
#2 0x00007ff6eda44ed8 in _bfd_coff_final_link (abfd=0x1a327bc62a0,
info=0x7ff6edd07880 <link_info>) at ../../binutils-gdb/bfd/cofflink.c:868
#3 0x00007ff6ed9e41ed in ldwrite () at ../../binutils-gdb/ld/ldwrite.c:545
#4 0x00007ff6ed9e0b7b in main (argc=79, argv=0x1a326035890)
at ../../binutils-gdb/ld/ldmain.c:513
(gdb) p *abfd
$1 = {filename = 0x1a32e13ac50 "libgobject_2_0_0_dll_d000431.o",
xvec = 0x7ff6edbcf220 <x86_64_pe_vec>, iostream = 0x0,
iovec = 0x7ff6edbb6280 <cache_iovec>, lru_prev = 0x0, lru_next = 0x0,
where = 0, mtime = 0, id = 2121, flags = 32825, format = bfd_object,
direction = read_direction, cacheable = 0, target_defaulted = 0,
opened_once = 0, mtime_set = 0, no_export = 0, output_has_begun = 0,
has_armap = 0, is_thin_archive = 0, no_element_cache = 0,
selective_search = 0, is_linker_output = 0, is_linker_input = 1,
plugin_format = bfd_plugin_unknown, lto_output = 0, lto_slim_object = 0,
read_only = 0, plugin_dummy_bfd = 0x0, origin = 72736,
proxy_origin = 72736, section_htab = {table = 0x1a32e1548a0,
newfunc = 0x7ff6eda26cfe <bfd_section_hash_newfunc>,
memory = 0x1a32d75c0d0, size = 4051, count = 5, entsize = 304,
frozen = 0}, sections = 0x1a32e1538a8, section_last = 0x1a32e153d68,
section_count = 5, archive_plugin_fd = -1,
archive_plugin_fd_open_count = 0, archive_pass = 0, alloc_size = 6561,
start_address = 0, outsymbols = 0x1a33339ae80, symcount = 8,
dynsymcount = 0, arch_info = 0x7ff6edbe9040 <bfd_x86_64_arch>, size = 0,
arelt_data = 0x1a32d75bfd0, my_archive = 0x1a32d75bd20, archive_next = 0x0,
archive_head = 0x0, nested_archives = 0x0, link = {next = 0x1a32e12ff80,
hash = 0x1a32e12ff80}, tdata = {aout_data = 0x1a32e13ac78,
aout_ar_data = 0x1a32e13ac78, coff_obj_data = 0x1a32e13ac78,
pe_obj_data = 0x1a32e13ac78, xcoff_obj_data = 0x1a32e13ac78,
ecoff_obj_data = 0x1a32e13ac78, srec_data = 0x1a32e13ac78,
verilog_data = 0x1a32e13ac78, ihex_data = 0x1a32e13ac78,
tekhex_data = 0x1a32e13ac78, elf_obj_data = 0x1a32e13ac78,
mmo_data = 0x1a32e13ac78, sun_core_data = 0x1a32e13ac78,
sco5_core_data = 0x1a32e13ac78, trad_core_data = 0x1a32e13ac78,
som_data = 0x1a32e13ac78, hpux_core_data = 0x1a32e13ac78,
hppabsd_core_data = 0x1a32e13ac78, sgi_core_data = 0x1a32e13ac78,
lynx_core_data = 0x1a32e13ac78, osf_core_data = 0x1a32e13ac78,
cisco_core_data = 0x1a32e13ac78, versados_data = 0x1a32e13ac78,
netbsd_core_data = 0x1a32e13ac78, mach_o_data = 0x1a32e13ac78,
mach_o_fat_data = 0x1a32e13ac78, plugin_data = 0x1a32e13ac78,
pef_data = 0x1a32e13ac78, pef_xlib_data = 0x1a32e13ac78,
sym_data = 0x1a32e13ac78, any = 0x1a32e13ac78}, usrdata = 0x1a32e15ccf0,
memory = 0x1a32d75bed0, build_id = 0x0}
(gdb) p *syment
$2 = {_n = {_n_name = "0\001\000\000\000\000\000", _n_n = {_n_zeroes = 304,
_n_offset = 13451671603782742029}, _n_nptr = {
0x130 <error: Cannot access memory at address 0x130>,
0xbaadf00dbaadf00d <error: Cannot access memory at address
0xbaadf00dbaadf00d>}}, n_value = 1, n_scnum = 0, n_flags = 61453, n_type =
49200,
n_sclass = 46 '.', n_numaux = 105 'i'}
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
