http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916
Patrick Marlier <patrick.marlier at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.marlier at gmail
| |dot com
--- Comment #7 from Patrick Marlier <patrick.marlier at gmail dot com>
2012-01-20 23:57:09 UTC ---
Some more info:
(gdb) bt
#0 0x00007fff884ec283 in exit ()
#1 0x0000000100e238fa in diagnostic_action_after_output (context=0x141397020,
diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:243
#2 0x0000000100e2477d in diagnostic_report_diagnostic (context=0x141397020,
diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:552
#3 0x0000000100e2589b in internal_error (gmsgid=0x100f076ef "in %s, at %s:%d")
at ../../trunk/gcc/diagnostic.c:845
#4 0x0000000100e25a35 in fancy_abort (file=Could not find the frame base for
"fancy_abort".
) at ../../trunk/gcc/diagnostic.c:899
#5 0x0000000100c72b41 in streamer_get_builtin_tree (ib=0x7fff5fbff070,
data_in=0x1419126a0) at ../../trunk/gcc/tree-streamer-in.c:1077
#6 0x0000000100853d12 in lto_input_tree (ib=0x7fff5fbff070,
data_in=0x1419126a0) at ../../trunk/gcc/lto-streamer-in.c:1175
#7 0x00000001000368f3 in lto_read_decls (decl_data=0x141f45000,
data=0x1420ac410, resolutions=0x0) at ../../trunk/gcc/lto/lto.c:925
#8 0x000000010003740c in lto_file_finalize (file_data=0x141f45000,
file=0x141903a10) at ../../trunk/gcc/lto/lto.c:1167
#9 0x000000010003744d in lto_create_files_from_ids (file=0x141903a10,
file_data=0x141f45000, count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1177
#10 0x0000000100037553 in lto_file_read (file=0x141903a10, resolution_file=0x0,
count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1217
#11 0x000000010003f5ec in read_cgraph_and_symbols (nfiles=2,
fnames=0x14190f300) at ../../trunk/gcc/lto/lto.c:2618
#12 0x0000000100040008 in lto_main () at ../../trunk/gcc/lto/lto.c:2932
#13 0x00000001009e7f29 in compile_file () at ../../trunk/gcc/toplev.c:557
#14 0x00000001009ead90 in do_compile () at ../../trunk/gcc/toplev.c:1938
#15 0x00000001009eaf15 in toplev_main (argc=17, argv=0x1419003c0) at
../../trunk/gcc/toplev.c:2014
#16 0x000000010004324e in main (argc=16, argv=0x7fff5fbff2b8) at
../../trunk/gcc/main.c:36
Fails as before the fcode corresponding to the TM_COMMIT.
The problem is that the lto-wrapper does not collect parameters from input
files.
The tracing brings me into libiberty, we see that simple_object_start_read
returns NULL with obj_0 or obj_1.
Breakpoint 1, run_gcc (argc=4, argv=0x7fff5fbff598) at
../../trunk/gcc/lto-wrapper.c:482
482 sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg,
&err);
(gdb) p argv[i]
$2 = 0x7fff5fbff751 "obj_0.o"
(gdb) n
483 if (!sobj)
(gdb) p sobj
$3 = (simple_object_read *) 0x0
Tracing a bit more, I see that simple_object_mach_o_match() ends with this:
*errmsg = "Mach-O file found but no segment name specified";
Indeed, lto-wrapper always gives NULL for the segment name.
sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg, &err);
So, since there is no documentation/specification of the
simple_object_start_read function I cannot say if it is a gcc/lto bug or a
libiberty bug.
Finally, there is a problem with lto-wrapper.c
if (!simple_object_find_section (sobj, LTO_SECTION_NAME_PREFIX "."
"opts",
&offset, &length, &errmsg, &err))
In MacOSX, I don't know the section name for opts (I have __wrapper_index,
__wrapper_sects, and __wrapper_names) but if I add the segment name "__GNU_LTO"
, the section name is ".gnu.lto_.opts" (not existing in my files).
To sum up, LTO files with MacOS does not supported opts or cannot be retrieve
in lto-wrapper. Need inputs from MacOS (and maybe LTO) maintainers...
Thanks!
Patrick Marlier.
