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 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.

Iain.