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

[Mark Morgan Lloyd]

Mark Morgan Lloyd wrote:
> Sven Barth wrote:
>> Am 08.08.2013 22:22, schrieb Mark Morgan Lloyd:
>>> Sven Barth wrote:
>>>
>>>>> 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
>>>
>>>>> 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.
>>>
>>> I'll take a look at that in the morning, probably by printing 
>>> temporary values etc. since I'm not very confident trying to 
>>> single-step somebody else's complex code. Allowing that this is 
>>> apparently a compiler rather than an fp/libgdb issue, is there test 
>>> code for this case anywhere?
>> We don't have an explicit test case for Min/Max.
>>> Misbehaving min()/max() rings a horrible bell, but I can't remember 
>>> the context.
>> Maybe it isn't Min/Max itself, but the direct passing of the result of 
>> the inner call to the outer call that's faulty on Sparc...
>>
>> Maybe you could compile a test program with a similar situation as the 
>> alignmentrequirement situation and check the parameter passing (if you 
>> can read Sparc assembly language)
> 
> Generally working on it. I'll be back.

I think min() and parameter passing are OK. The problem appears to be 
that the length of [whatever] is zero, and this is propagating via 
alignmentrequirement to the mod operation. From debugging output, this 
/only/ appears to happen when building fp with libgdb, 2.6.2 will 
compile e.g. Lazarus 1.0 and produce something which looks generally OK.

If as the worst-possible kind of hack I do this

                         else
                           begin
{ TODO: HACK: unaligned test, maybe remove all unaligned locations 
(array of char) from the compiler}
                             { Use unaligned copy when the offset is not 
aligned }
                             len:=left.resultdef.size;
if len <= 0 then
   len := sizeof(aint);
                             { data smaller than an aint has less 
alignment requirements }

it fixes the compilation problem.

If nobody has any head-slappingly obvious quick fixes, is there any 
comparatively-simple way that I can at least report on what it's trying 
to compile that's causing the fault?

I'm left with issues like

..
Using assembler: /usr/bin/as
/usr/local/src/fpc/fpcbuild-2.6.2/fpcsrc/libgdb/linux/sparc/libgdb.a(ada-lang.o): 
In function `scaling_factor':
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/ada-lang.c:8651: undefined 
reference to `_Q_utoq'
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/ada-lang.c:8651: undefined 
reference to `_Q_utoq'
..

which I've not seen previously. Unless anybody has any suggestions (and 
time permitting) I'll take a look at older versions and try to work out 
when things started going wrong.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]