[M3devel] strange errors...

[Tony Hosking]

This looks like a debug symbol problem that others have reported.   
Please try the following:  replace the -g option to the backend in  
your cm3.cfg with -gstabs or -gstabs+ and let me know what happens.

On Jun 25, 2007, at 4:03 AM, Mika Nystrom wrote:

> Guten Tag Olaf!
>
> --- building in FreeBSD4 ---
>
> cd FreeBSD4
> ignoring ../src/m3overrides
>
> rm .M3SHIP
> rm .M3OVERRIDES
> inhale libm3core.m3x
>
> new source -> compiling RTHooks.i3
> m3front ../src/runtime/common/RTHooks.i3 -w1
> /usr/local/cm3/bin/cm3cg -quiet RTHooks.ic -o RTHooks.is -g
> RTHooks.i3: In function 'RTHooks_I3':
> RTHooks.i3:146: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> rm RTHooks.is
>
>
> I figured that building cm3cg with debugging symbols involves
> running "cm3 -DM3CC_CFLAGS=-g" (not completely obvious), and
> obtained the following:
>
> (gdb) run -quiet RTHooks.ic -o RTHooks.is -g
> Starting program: /usr/local/cm3/bin/cm3cg -quiet RTHooks.ic -o  
> RTHooks.is -g
>
> Program received signal SIGSEGV, Segmentation fault0x080f614b in  
> gen_field_die (decl=0x6873f228, context_die=0x68714208) at ../../ 
> gcc/gcc/dwarf2out.c:12079
> 12079     if (TREE_CODE (DECL_FIELD_CONTEXT (decl)) != UNION_TYPE)
> (gdb) where
> #0  0x080f614b in gen_field_die (decl=0x6873f228,  
> context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:12079
> #1  0x080f7ad6 in gen_decl_die (decl=0x6873f228,  
> context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:13121
> #2  0x080f671d in gen_member_die (type=0x6873f33c,  
> context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:12280
> #3  0x080f69e4 in gen_struct_or_union_type_die (type=0x6873f33c,  
> context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:12357
> #4  0x080f6f0f in gen_type_die (type=0x6873f33c,  
> context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:12562
> #5  0x080f79a0 in gen_decl_die (decl=0x6871c548,  
> context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:13072
> #6  0x080f808b in dwarf2out_decl (decl=0x6871c548) at ../../gcc/gcc/ 
> dwarf2out.c:13371
> #7  0x080f7ceb in dwarf2out_type_decl (decl=0x6871c548, local=0)  
> at ../../gcc/gcc/dwarf2out.c:13183
> #8  0x0804c48b in debug_struct () at ../../gcc/gcc/m3cg/parse.c:1762
> #9  0x0804de17 in m3cg_declare_formal () at ../../gcc/gcc/m3cg/ 
> parse.c:2463
> #10 0x08053941 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/ 
> parse.c:4773
> #11 0x082eec3b in compile_file () at ../../gcc/gcc/toplev.c:991
> #12 0x082f018a in do_compile () at ../../gcc/gcc/toplev.c:1949
> #13 0x082f01f2 in toplev_main (argc=6, argv=0xbfbfe3bc) at ../../ 
> gcc/gcc/toplev.c:1981
> #14 0x0805a2ae in main (argc=6, argv=0xbfbfe3bc) at ../../gcc/gcc/ 
> main.c:35
> (gdb) print decl
> $1 = 0x6873f228
> (gdb) whatis decl
> type = tree
> (gdb) print *decl
> $2 = {common = {chain = 0x6873f284, type = 0x68716284, ann = 0x0,  
> code = FIELD_DECL, ... [large data structure follows]
> (gdb) whatis context_die
> type = dw_die_ref
> (gdb) print *context_die
> $5 = {die_tag = DW_TAG_structure_type, die_symbol = 0x0, die_attr =  
> 0x68708fc0, die_parent = 0x68714138, die_child = 0x6871423c,  
> die_sib = 0x0, die_definition = 0x0, die_offset = 0,
>   die_abbrev = 0, die_mark = 0, decl_id = 0}
>
>
> Here I must confess I have never debugged parts of gcc before...
>
> If it helps, I put RTHooks.ic at http://www.async.caltech.edu/~mika/ 
> RTHooks.ic
> Maybe someone can use this to tell whether it is m3front or cm3cg  
> that is (more) broken.
>
> Are the .ic files architecture-independent?
>
>     Mika
>
>
>
> "Olaf Wagner" writes:
>> On Mon, June 25, 2007 5:47 am, Mika Nystrom wrote:
>>> Yes, cm3 is just reporting it, I think.  I assume it's cm3cg that's
>>> segfaulting:
>>>
>>> (compiling m3core)
>>>
>> --- building in FreeBSD4 ---
>>>
>>> ignoring ../src/m3overrides
>>>
>>> new source -> compiling RTHooks.i3
>>> RTHooks.i3: In function 'RTHooks_I3':
>>> RTHooks.i3:146: internal compiler error: Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>> new source -> compiling RT0.i3
>>> RT0.i3: In function 'RT0_I3':
>>> RT0.i3:230: internal compiler error: Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>
>> This looks really broken :-(
>> Please use the cm3 options -commands to see the actual backend  
>> executions
>> and -keep to save the input data which provokes gcc to give up.
>> You can then use gdb on cm3cg to get a backtrace and try to figure  
>> out
>> what's going wrong. A backtrace of cm3cg will probably be most  
>> helpful.
>>
>> Olaf
>>
>> PS: As for automation of the installation and upgrade process, this
>>    used to work fine some time ago. The problem seems to be that  
>> nobody
>>    really does extensive testing of fresh installations unless Elego
>>    pays some student for release engineering :-/ I think we should
>>    just try to keep the existing installation scripts up-to-date;
>>    perhaps add a bit more information. For example, if the m3gc-xxx
>>    packages are not needed anymore, we should simply remove them from
>>    all current scripts. It would also be helpful if we had a  
>> tinderbox
>>    system that does regular builds at least on some reference  
>> platforms.
>> PPS: Antony, did you change anything recently regarding code  
>> generation
>>    that could cause such failures as above?
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179  
>> Berlin, Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30  
>> 23 45 86 95
>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>> DE163214194