Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw <ibuclaw@gdcproject.org>]

Excerpts from Iain Buclaw's message of September 6, 2022 11:41 pm:
> Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
>> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>>> Hi Iain,
>>> 
>>>>> there is indeed ;-)  The previous d21 emits
>>>>> 
>>>>> binary    ./266566/gcc/d21
>>>>> version   v2.100.1
>>>>> 
>>>>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>>>>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>>>>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
>>>>> Posix Solaris CppRuntime_Gcc
>>>>> 
>>>>> while the patched one gives
>>>>> 
>>>>> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
>>>>> index [3530971477] is out of bounds for array of length 0
>>>>> gcc.deh(505): uncaught exception
>>>>> <built-in>: internal compiler error: Abort
>>>>> 0x96d5b6c crash_signal
>>>>> 	/var/gcc/reghunt/master/gcc/toplev.cc:314
>>>>> 
>>>>
>>>> Excellent, and the stage1 compiler?
>>> 
>>> binary    ./prev-gcc/d21
>>> version   v2.100.1
>>> 
>>> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix Solaris CppRuntime_Gcc
>>> 
>>> So identical to the pre-patch one.
>>> 
>>> Just in case, here's the stacktrace of the crashing d21, filtered
>>> through c++filt -s dlang:
>>> 
>>> Thread 2 received signal SIGABRT, Aborted.
>>> [Switching to Thread 1 (LWP 1)]
>>> 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> (gdb) bt
>>> #0  0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> #1  0xfe1b62cf in thr_kill () from /lib/libc.so.1
>>> #2  0xfe0ed662 in raise () from /lib/libc.so.1
>>> #3  0xfe0bae74 in abort () from /lib/libc.so.1
>>> #4  0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=..., line=<optimized out>) at /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
>>> #5  0x0a8e7ab3 in _d_throw (object=<optimized out>) at /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
>>> #6  0x0a8edf02 in onArrayIndexError (index=<optimized out>, length=<optimized out>, file=..., line=<optimized out>) at /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
>>> #7  0x0a8edf3d in _d_arraybounds_indexp (file=<optimized out>, line=<optimized out>, index=<optimized out>, length=<optimized out>) at /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
>>> #8  0x08ffc17a in dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint, scope const(char)[]) const (this=..., hash=<optimized out>, str=...) at /var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291
>> 
>> Yeah, I don't see how that could trigger, as the value of `i` is always
>> adjusted to `i &= (table.length - 1)` (it uses quadratic probing to search
>> the hash table).
>> 
>> The logic of the compiler doesn't appear to have changed, but the data
>> layout may have, so I'm suspecting an issue that was always there has
>> now surfaced to the fore.
>> 
> 
> Yes, this is data related. The DSO registry picks up nothing in the
> miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
> compiler works, and runs all module constructors ahead of compilation.
> 

Ohh, backtrack on that, analysis is correct, but it is a compiler regression.

The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no
longer get pulled in to sol2-d.cc after I removed the tm.h include.

Re-adding these two ought to fix the bootstrap for you.

    #include "tm.h"
    #include "memmodel.h"

Iain