Bug 399012 - ti.targets.arm.ARP32_far link may fail
Summary: ti.targets.arm.ARP32_far link may fail
Status: ASSIGNED
Alias: None
Product: RTSC (ARCHIVED)
Classification: Technology
Component: Targets (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Dave Russo CLA
QA Contact:
URL:
Whiteboard:
Keywords: readme
Depends on:
Blocks:
 
Reported: 2013-01-24 14:35 EST by Dave Russo CLA
Modified: 2013-05-07 21:49 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Russo CLA 2013-01-24 14:35:11 EST
xdctest-b19 fails to link an example with the following ARP32 linker error:

lnkearp32F client_debug.xearp32F ...
"args_main.c", line ? (approximate): warning: relocation from function
   "_args_main" to symbol "__c_args__" overflowed; the 9-bit relocated address
   0xf16 is too large to encode in the 19-bit unsigned field (type =
   'R_ARP32_SBR_U19_W' (23), file "$LINUXPATH/rtsarp32_v200.lib<args_main.obj>", offset = 0x00000020, section = ".text:_args_main")
warning: output file "client_debug.xearp32F" cannot be loaded and run on a target system


This might be caused by a .args section placement issue.
Comment 1 Karl Wechsler CLA 2013-03-14 19:16:03 EDT
+ others …

 

I finally looked into this today.

 

The problem appears to be related to how the RTS library is built for the ARP32.  

 

It looks like the RTS library is build for default data model which is similar to C6x’s near data model.  All data (.const, .bss, .args) needs to be within a memory region.  If I place .args in “DDR” and .bss in “DMEM”, I can reproduce this problem.   If I put them both in “DDR” or both in “DMEM” all is well.


The reason we do not see this with SYS/BIOS programs is that we set .args size to 0 by default for SYS/BIOS programs (--args = 0).

 

xxx – I wonder if the RTS library for the ARP32 should be compiled for far data model?   I think this would allow it to be linked with .obj files that use either near data or far data.  I think this is how the C6x runtime is built?  (not sure).  The performance of far data is only marginally worse than near data in most cases and I doubt it would matter for RTS code.   If not, then I think you need to provide 2 versions of the RTS library?  One for near model users and the other for far model users?  I think I’m going to reject this bug as not a bug in XDC.  I file a new bug against codegen -- SDSCM00046732.

 

-Karl-