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

[Sven Barth]

On 09.08.2013 14:55, Mark Morgan Lloyd wrote:
> 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?

So you changed the "len = 0" to "len <= 0"? Then this is very strange, 
because that almost surely shouldn't happen. Could you please print 
somehow (either debugging or Writeln) the value of left.resultdef.typ 
(yes, without "e" at the end!) when len <= 0? Then we could at least 
check which def produces problematic results here (is suspect records, 
but just to be sure).

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

This isn't related to FPC itself however. Here libgdb has some 
unresolved symbols.

Regards,
Sven