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

Mark Morgan Lloyd markMLl.fpc-devel at telemetry.co.uk
Sat Aug 10 00:40:44 CEST 2013


Sven Barth wrote:
> On 09.08.2013 21:20, Sven Barth wrote:
>>>  > 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).
>>>
>>> That of course was one of the things I was asking :-) With code as below
>>> (reformatted to avoid problems with wrap)
>>>
>>> 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 begin
>>>    WriteLn('=====> len: ', len);
>>>    WriteLn('=====> typ: ', left.resultdef.typ)
>>> end;
>>> // if len <= 0 then
>>> //   len := sizeof(aint);
>>>
>>> { data smaller than an aint has less alignment requirements }
>>>      alignmentrequirement:=min(len,sizeof(aint));
>>>      if (right.location.reference.offset mod alignmentrequirement<>0) or
>>> ..
>>>
>>> I get
>>>
>>> =====> len: 0
>>> =====> typ: recorddef
>>>
>>> But it does appear to build properly on x86, without any zero-length
>>> types.
>>
>> Ok, so it is indeed a record that calculates the wrong size. Could you
>> please add the following code after the assignment of "len" and tell me
>> the output, so that we'll know which record exactly is the one that 
>> fails?
>>
>> === code begin ===
>>
>> if len=0 then
>>    begin
>>      if left.resultdef.typ=recorddef then
>>        writeln('=======> objname: ',trecorddef(left.resultdef).objname^);
>>      len:=sizeof(pint);
>>    end;
>>
>> === code end ===
>>
>> I'll meanwhile investigate how a record calculates its size.
> 
> You might additionally add the following code to the end of the these 
> methods of "tabstractsymtable" in unit "symtable":
> - setdatasize
> - addfield
> - addalignmentpadding
> and also to "trecordsymtable.insertunionst" (also unit "symtable"):
> 
> === code begin ===
> 
> if _datasize=0 then
>   begin
>     write('======> _datasize = 0 @', {$I %LINE%}, ': ');
>     if assigned(defowner) and (defowner.typ=recorddef) then
>       writeln(trecorddef(defowner).objname^)
>     else
>       writeln('<unknown>');
>   end;
> 
> === code end ===

======> _datasize = 0 @1138:
======> _datasize = 0 @1138:
======> _datasize = 0 @1068: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
/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'

1027 .addfield
1068 .addalignmentpadding
1138 .setdatasize

More later.

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

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



More information about the fpc-devel mailing list