Closed mheyer32 closed 3 years ago
It builds again, but doesn't run - even with -flto disabled. It'll just crash :-( The '-flto' compiler switch can be found in dopus5allamigas/source/makefile.comon
I'll let you know once I dug a bit deeper.
I think this might be a regression related to https://github.com/bebbo/gcc/issues/137#issue-776812265
When looking at ADoom, I can see that the a5 parameter passed into c2p_6_020 (this will be used when choosing an EHB screen modes) gets screwed up again.
DOpus also makes use of A5 in a few places.
the inline macros are using d7 instead of a5 plus an exg d7,a5 before and after the function call. I guess you have to establish something similar to be safe.
The A5 thingy was a red herring - that's not it. Also, even with -fbbb=-
I experience crashes.
Continueing the investigation.
what's the last working version?
IDK - I hadn't recompiled DOpus in a while. Do you have a suggestion for a known good version of GCC I could start a bisection with?
try this one please: e0013462782186e62d08d7426da2127d24d00e7d
This one crashes the compiler:
>>>>>Compiling window_activate.c
(insn 1082 1206 1205 73 (set (mem:QI (post_inc:SI (reg:SI 8 a0)) [0 MEM[base: _60, offset: 0B]+0 S1 A8])
(plus:QI (mem:QI (reg:SI 9 a1) [0 S1 A8])
(reg:QI 0 d0 [ _RandomDopus_re+1 ]))) function_copy.c:1566 141 {addqi3}
(expr_list:REG_INC (reg:SI 8 a0)
(nil)))
function_copy.c: In function 'function_copy_file':
function_copy.c:1737:1: error: insn does not satisfy its constraints:
}
^
(insn 1082 1206 1205 73 (set (mem:QI (post_inc:SI (reg:SI 8 a0)) [0 MEM[base: _60, offset: 0B]+0 S1 A8])
(plus:QI (mem:QI (reg:SI 9 a1) [0 S1 A8])
(reg:QI 0 d0 [ _RandomDopus_re+1 ]))) function_copy.c:1566 141 {addqi3}
(expr_list:REG_INC (reg:SI 8 a0)
(nil)))
function_copy.c:1737:1: internal compiler error: in extract_constrain_insn, at recog.c:2199
Please submit a full bug report,
with preprocessed source if appropriate.
hm - maybe: c0d957cf8ba93e529a1f3ca04d4c741ea267f254
I got a lead. The issue was that when DOpus opens xadopus.module, it'll try to find and read a string from its built-in catalog. That would never return and eventually the machine would crash.
// Locale marker
struct DOpusLocale
{
APTR li_LocaleBase;
APTR li_Catalog;
char *li_BuiltIn; <<<<<<<<<<<< pointing to the list of strings in its own catalog defined by 'XADopus_Block'
struct Locale *li_Locale;
};
I later found that somewhere along the way the li_BuiltIn pointer got corrupted and thus sending L_GetString() into the weeds.
This happens in source/Modules/xadopus/init/libinit.c at this place:
// Allocate and open locale data
if(!(locale=AllocVec(sizeof(struct DOpusLocale),MEMF_CLEAR)))
return 1;
init_locale_data(locale);
bug("locale: 0x%lx locale->li_BuiltIn %lx : %s", locale, locale->li_BuiltIn, locale->li_BuiltIn);
// Open locale library
if((LocaleBase=(APTR)OpenLibrary("locale.library",38)))
{
// Initialise catalog
locale->li_LocaleBase=LocaleBase;
if(module_info.locale_name) locale->li_Catalog=OpenCatalogA(NULL,module_info.locale_name,0);
locale->li_Locale=OpenLocale(0);
}
bug("locale: 0x%lx locale->li_BuiltIn %lx : %s", locale, locale->li_BuiltIn, locale->li_BuiltIn);
The last bug() output already shows that the locale->li_BuiltIn had been modified somewhere inside the if() clause.
Looking at the asm, I believe there's some issue either with symbol reloading or wrong accounting for auto-increment happening:
if((LocaleBase=(APTR)OpenLibrary("locale.library",38)))
796: movea.l 0 0 __start,a6
79c: moveq #38,d0
79e: lea 5a2 5a2 _freeBase+0x238(pc),a1
7a2: jsr -552(a6)
7a6: move.l d0,10 10 _exit+0xc
7ac: addq.l #4,sp
7ae: beq.s 758 758 _UserLibInit+0x1e
locale->li_LocaleBase=LocaleBase;
7b0: movea.l 0 0 __start,a3 >>>>>>>>> points to li_LocalBase
7b6: move.l d0,(a3)+ >>>>>>>>>> now points to li_Catalog
if(module_info.locale_name) locale->li_Catalog=OpenCatalogA(NULL,module_info.locale_name,0);
7b8: movea.l 8 8 _exit+0x4,a1
7be: move.l a1,d1
7c0: beq.s 7d6 7d6 _UserLibInit+0x9c
7c2: lea 0 0 __start,a2
7c6: movea.l a2,a0
7c8: movea.l d0,a6
7ca: jsr -150(a6)
7ce: move.l d0,(a3) // update li_Catalog
7d0: movea.l 0 0 __start,a3 // RELOAD locale, again pointing back to li_LocalBase
locale->li_Locale=OpenLocale(0);
7d6: lea 0 0 __start,a0
7da: movea.l 10 10 _exit+0xc,a6
7e0: jsr -156(a6)
7e4: move.l d0,8(a3) // HERE's the bug: 8(a3) is pointing to li_BuiltIn, not li_Locale; li_BuiltIn gets corrupted
return 0;
7e8: clr.l d0
7ea: bra.w 758 758 _UserLibInit+0x1e
so this here: https://franke.ms/cex/z/T1TMdx
Yep, I'm glad its reproducing in the explorer! Its doing the same thing
move.l _locale,a2
.L5:
clr.l -(sp)
jsr _OpenLocale
move.l d0,(8,a2) << should be 12 or above reload of _locale could be avoided
but -fbbb=-
avoids it - and yes, it's a bug. The path after the assignment must not intersect the modified path
but -fbbb=- avoids it - and yes, it's a bug. The path after the assignment must not intersect the modified path
Yes, sorry, that probably was some mistake on my side. At the same time I also have an issue with ADoom's EHB mode. That is something I still need to figure out...
please test
That didn't do it. The code remained unchanged. I did a complete clean & rebuild of the toolchain. Compiler Explorer also still shows the old code.
... I forgot one change - there are so many pending changes^^
Sind wir nicht alle ein bisschen bluna? :-D
That still wasn't enough. This one is stubborn.
on cex it's ok now (you have to wait for the nightly cex (or manual by me) update and force recompiling)
You can see for yourself:
take -flto out of makefile.common
then compile with
make os3 release debug=no -j8
then
m68k-amigaos-objdump -m68020-60 --no-show-raw-insn -d -S Modules/xadopus/init/libinit.o > libinit.asm
and search for
if((LocaleBase=(APTR)OpenLibrary("locale.library",38)))
all good things come in threes...
Third time works a charm!
Closing!
Compiling the master branch at https://github.com/mheyer32/dopus5allamigas via make os3 release debug=no fails with: