[fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

[Sven Barth]

On 08.08.2013 19:08, Mark Morgan Lloyd wrote:
> Mark Morgan Lloyd wrote:
>
>> Fatal: Compilation aborted
>> An unhandled exception occurred at $001E61C0 :
>> EDivByZero : Division by zero
>>   $001E61C0  TCGASSIGNMENTNODE__PASS_GENERATE_CODE,  line 785 of
>> ncgld.pas
>>
>> At this point: what's actually running, i.e. what command should I
>> apply gdb to to get a decent backtrace?
>
> If I revert to 2.6.2 and run ppcsparc under gdb, I get this as a backtrace:
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at
> ncgld.pas:785
> 785                                 if (right.location.reference.offset
> mod alignmentrequirement<>0) or
> (gdb) bt
> #0  0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE
> (this=0xf5d6abe0) at ncgld.pas:785
> #1  0x0014d9c4 in SECONDPASS (P=0xf5d6abe0) at pass_2.pas:195
> #2  0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1d320) at
> ncgbas.pas:366
> #3  0x0014d9c4 in SECONDPASS (P=0xf5b1d320) at pass_2.pas:195
> #4  0x001dc2b4 in TCGIFNODE__PASS_GENERATE_CODE (this=0xf5d737f0) at
> ncgflw.pas:275
> #5  0x0014d9c4 in SECONDPASS (P=0xf5d737f0) at pass_2.pas:195
> #6  0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1c0a0) at
> ncgbas.pas:366
> #7  0x0014d9c4 in SECONDPASS (P=0xf5b1c0a0) at pass_2.pas:195
> #8  0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1eaa0) at
> ncgbas.pas:366
> #9  0x0014d9c4 in SECONDPASS (P=0xf5b1eaa0) at pass_2.pas:195
> #10 0x0014db14 in DO_SECONDPASS (P=0xf5b1eaa0) at pass_2.pas:227
> #11 0x0016a368 in TCGPROCINFO__GENERATE_CODE (this=0xf6357cd0) at
> psub.pas:1048
> #12 0x0016c170 in DO_GENERATE_CODE (PI=0xf6357cd0, parentfp=0xffed8790)
> at psub.pas:1557
> ..
>
> Also (if I'm doing this right)
>
> (gdb) print alignmentrequirement
> $1 = 0
>
> Any thoughts appreciated.
>

This is strange. If you take a look at the code there are at least two 
checks that should ensure that alignmentrequirement is not 0... Could 
you maybe step into Min and Max to check whether they produce sane 
results? (you'll likely need to recompile the RTL with debug 
information; I'd suggest you to use 2.7.1 for debugging)
If you can't recompile the RTL with debug information you could try to 
break up the assignment statement for "alignmentrequirement" into single 
steps and print the values so that we can have a complete picture.

Regards,
Sven