Ticket #466 (Fixed)Tue Apr 30 15:05:26 UTC 2019
VFP causes Link to data abort
Reported by: | Richard Coleman (3190) | Severity: | Normal |
Part: | RISC OS: C/C++ toolchain | Release: | |
Milestone: | Status | Fixed |
Details by Richard Coleman (3190):
Have been looking at using VFP with ObjAsm and came across -APCS 3/32bit/vfp in cvsroot.mixed.RiscOS.Library.ToolOptions.APCS-32,feb
which is currently only used by BasicVFP.
Using that ObjAsm creates the object file but then Link causes a data abort on imported symbols.
Example code, save as “Textfile1” …
<pre><code>
AREA |Asm$Code|, CODE, READONLY, PIC
ENTRY
AREA |Asm$Data|, DATA, READWRITE, PICfirst DCFD 123.456
DCD |Image$$RO$$Base|
END
</code></pre>
I know the above code doesn’t actually work but it does demonstrate the problem.
It will assemble just fine with the DCFD value being written in VFP format and Link will then make an AIF file with no warnings about FP calling conflicts.
But remove [DATA]
in Textfile1 or replace it with anything else other than [NOFPREGARGS]
and whilst the object file will be created correctly, Link will abort as below …
Tested on ARMX6 RISC OS 5.25 (25 Apr 2018)
Link version 5.36 [16 Mar 2014]
<pre>
*objasm -cpu 6Z -APCS 3/32bit/vfp —fpu VFPv2 $.Textfile1 -o $.object1
ARM AOF Macro Assembler 4.05 (Acorn Computers Ltd) [19 Mar 2018]
*link $.object1 -o $.aoffile
ARM Linker: (Warning) Code/data or FP calling standard conflict for symbol Image$$RO$$Base (in
Internal error: abort on data transfer at &FC1444BC
Postmortem requested
Arg5: 00000000 0
Arg4: 0xfc13ec44 -65803196 -> [0xe3a00000 0xe1a0f00e 0xe1a0c00d 0xe92d000f]
Arg3: 0×00021e78 138872 -> [0×00021ea4 0×00021fd0 0×0001f160 0×00020154]
Arg2: 0×0000c66d 50797
Arg1: 0×0002060c 132620 -> [0×000223cc 00000000 00000000 0×00452402]
fc1444b4 in shared library function
fc13ef44 in shared library function
Arg5: 0×0002e0d4 188628 -> [00000000 0×0002e0b8 0×6d492121 0×24656761]
Arg4: 0×0002e228 188968 -> [0×656a626f 0×00317463 00000000 0×0002e228]
Arg3: 0xe59ff488 -442502008
Arg2: 0×0001ffca 131018
Arg1: 0×0000c66c 50796 -> [0×646f4331 0×61642f65 0×6f206174 0×50462072]
8ca0 in anonymous function
c574 in anonymous function
ea9c in anonymous function
eb8c in anonymous function
126c8 in anonymous function
1a054 in anonymous function
Arg2: 0×00019684 104068 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe15d000a]
Arg1: 0×000220d4 139476 -> [0×6b6e696c 0×6d617220 0×2e303a3a 0×626f2e24]
fc135010 in shared library function
1dd60 in anonymous function
*where
Address &FC1444BC is at offset &00013594 in module ‘SharedCLibrary’
*showregs
Register dump (stored at &200117F0) is:
R0 = E59FF488 R1 = E59FF488 R2 = 00021EA0 R3 = E59FF489
R4 = 00000000 R5 = 0002060C R6 = 00021E78 R7 = 0000C6AB
R8 = 00000073 R9 = 00000049 R10 = 00021330 R11 = 00021E50
R12 = 01010101 R13 = 00021E00 R14 = 80808080 R15 = FC1444BC
Mode USR32 flags set: nZCvqjggggeAift PSR = 60000110
*memoryi PC-20 + 40
FC14449C : ..Qã : E3510000 : CMP R1,#0
FC1444A0 : …. : 0A000010 : BEQ &FC1444E8
FC1444A4 : …ã : E3100003 : TST R0,#3
FC1444A8 : úÿÿ. : 1AFFFFFA : BNE &FC144498
FC1444AC : Æ.å : E51FC620 : LDR R12,&FC143E94
FC1444B0 : Œã á : E1A0E38C : MOV R14,R12,LSL #7
FC1444B4 : ..ä : E4901004 : LDR R1,[R0],#4
FC1444B8 : . Aà : E041200C : SUB R2,R1,R12
FC1444BC < . Âá : E1C22001 : BIC R2,R2,R1
FC1444C0 : …á : E112000E : TST R2,R14
FC1444C4 : úÿÿ. : 0AFFFFFA : BEQ &FC1444B4
FC1444C8 : ÿ..ã : E31100FF : TST R1,#&FF ; =“ÿ”
FC1444CC : ... : 02400003 : SUBEQ R0,R0,#3
FC1444D0 : .... : 0A000004 : BEQ &FC1444E8
FC1444D4 : ÿ..ã : E3110CFF : TST R1,#&FF00
FC1444D8 : ..
. : 02400002 : SUBEQ R0,R0,#2
</pre>
Changelog:
Modified by Richard Coleman (3190) Wed, May 01 2019 - 21:21:57 GMT
- Part changed from Unspecified to RISC OS: C/C++ toolchain
Modified by Richard Coleman (3190) Wed, May 08 2019 - 21:59:27 GMT
Have received update from ROOL that this is caused by Image$$RO$$Base not being associated with an AOF file, so the filename was unset, causing an abort.
A fix is in the pipeline.
Will close ticket once fix has been released.
Modified by Sprow (202) Sat, December 21 2019 - 17:58:04 GMT
- Status changed from Open to Fixed
From the DDE29 change log for Link:
Changes from 5.36 to 5.37
=====
An abort caused when printing a diagnostic message when conflicting FP
calling standards appeared in the AOF area flags were encountered has been
fixed.