RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account

Previous|Next

  • Tickets
  • » Ticket #466

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

IMPORT |Image$$RO$$Base| [DATA]

ENTRY

AREA |Asm$Data|, DATA, READWRITE, PIC

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

  • Comment on, or change status of, this ticket

Previous|Next

Search tickets

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Options

  • Tickets
  • New ticket
  • Milestones
  • Subversion: Changesets
  • Subversion: Browse
  • CVS: Revisions
  • CVS: Browse
  • Search

RSS feeds Rss

  • Tickets
  • Everything!
  • More feeds...
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Collaboa theme is distantly based on the Collaboa default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Collaboa
This site runs on Rails

Hosted by Arachsys