[Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

[peter green]

On 26/01/17 07:01, Graham Inggs wrote:
> The patch below adds line number information to the generated parconvert.s:
>
> --- a/dcm2nii/dcm2nii.lpi
> +++ b/dcm2nii/dcm2nii.lpi
> @@ -482,6 +482,7 @@
>           <ConfigFilePath Value=""/>
>         </ConfigFile>
>         <CompilerPath Value="$(CompPath)"/>
> +      <CustomOptions Value="-al"/>
>       </Other>
>     </CompilerOptions>
>     <EditorMacros Count="0"/>
>
> Because of the additional lines, this changes the assembler messages to:
>
> (9009) Assembling parconvert
> parconvert.s: Assembler messages:
> parconvert.s:3775: Error: co-processor offset out of range
> parconvert.s:3783: Error: co-processor offset out of range
> parconvert.s:3880: Error: co-processor offset out of range
> parconvert.s:3886: Error: co-processor offset out of range
> parconvert.s:3892: Error: co-processor offset out of range
> parconvert.s:3895: Error: co-processor offset out of range
> parconvert.s:3899: Error: co-processor offset out of range
> parconvert.s:3903: Error: co-processor offset out of range
> parconvert.s:3918: Error: co-processor offset out of range
> parconvert.s:3924: Error: co-processor offset out of range
> parconvert.s:3930: Error: co-processor offset out of range
> parconvert.s:4813: Error: co-processor offset out of range
> parconvert.s:4817: Error: co-processor offset out of range
> parconvert.s:4821: Error: co-processor offset out of range
> parconvert.s:4825: Error: co-processor offset out of range
> parconvert.s:4895: Error: co-processor offset out of range
> parconvert.s:4899: Error: co-processor offset out of range
> parconvert.pas(1375) Error: (9007) Error while assembling exitcode 1
> parconvert.pas(1375) Fatal: (10026) There were 2 errors compiling
> module, stopping
> Fatal: (1018) Compilation aborted
>
> The first error corresponds to the vstr instruction on line 3775 below:
>
> # [593] lScanResX :=  round(readParFloat);
>      mov    r0,r11
>      blx    PARCONVERT$_$READ_PAR2NII$crcDDE5A164_$$_READPARFLOAT$$DOUBLE
>      blx    fpc_round_real
>      blx    fpc_int64_to_double
>      vmov.f64    d1,d0
>      sub    r0,r11,#143360
>      vstr    d1,[r0, #-2528]
>
> Which in turn, corresponds to line 593 of parconvert.pas:
>
>        if lUpCaseStr = 'SCANRESOLUTION(XY)' then begin
>           lScanResX :=  round(readParFloat);
>           lScanResY :=  round(readParFloat);
>
> readParFloat is a nested function returning double, starting on line
> 461 of parconvert.pas:
>
> function readParFloat:double;//nested
> var lStr: string;
> begin
>    lStr := '';
>    result := 1;
> ...
I don't think the implemention of readParFloat is relavent. The actual calls to readparfloat, round and int64 to double all assemble fine, things break down when it tries to store the result in a local variable.

What I think is happening is that the stackframe has got too big and so the offset in the floating point store operation has got bigger than the architecture can handle. I am having trouble figuring out the compiler source but it looks like there may be no code to limit the offsets used for floating point stores in local variable accesses.

I tried rearanging the local variable declarations but that seemed to make no difference.

I found it was possible to make the code build by reducing "kMaxnSLices" to 9000 but I don't know what the functional impact of that is.

> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel
>