Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Real-Time Software Components (RTSC) » Trouble building for the GCArmv7A target
Trouble building for the GCArmv7A target [message #1447658] Sat, 18 October 2014 17:46 Go to next message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
I am trying to build my first RTSC application (as a package) which uses a package I also created. The "collections" package I created implements only one module called "Queue". I have no problems building the package itself for the following targets:

======== config.bld ========
var Build = xdc.useModule('xdc.bld.BuildEnvironment');

var MINGW = xdc.useModule('gnu.targets.Mingw');
var MINGW_ROOT = java.lang.System.getenv("MINGW_ROOT");
MINGW.rootDir = MINGW_ROOT;
MINGW.ccOpts.prefix = "-m32 -O2";

var ARMLinux = xdc.useModule('gnu.targets.arm.GCArmv7A');
var LINARO_LINUX_ROOT = java.lang.System.getenv("LINARO_LINUX_ROOT");
ARMLinux.rootDir = LINARO_LINUX_ROOT
ARMLinux.LONGNAME = "bin/arm-linux-gnueabi-gcc.exe";

var C64P = xdc.useModule('ti.targets.C64P');
C64P.rootDir = "C:/ti/ccsv6/tools/compiler/c6000_7.4.8";

//Build.targets = [C64P, MINGW, ARMLinux];


My test application, however, fails with an internal compiler error for the GCArmv7A target:

C:\MyRepos\examples\test>xdc all
making package.mak (because of package.bld) ...
generating interfaces for package test (because package/package.xdc.inc is older than package.xdc) ...
configuring prog.xv7A from package/cfg/prog_pv7A.cfg ...
clv7A package/cfg/prog_pv7A.c ...
package/cfg/prog_pv7A.c:4983:1: internal compiler error: in get_variable_section, at varasm.c:1012
Please submit a full bug report,
with preprocessed source if appropriate.
See <link removed> for instructions.
gmake.exe: *** [package/cfg/prog_pv7A.ov7A] Error 1

I have searched for this error and have not found any helpful leads. I use the Linaro 2012.04 toolchain for Windows quite extensively outside RTSC and have not had this issue. Here is the code for the "collections" package:

======== Package.bld ========
var Build = xdc.useModule('xdc.bld.BuildEnvironment');
var Pkg   = xdc.useModule('xdc.bld.PackageContents');

for each (var targ in Build.targets)
{
	Pkg.addLibrary("lib/" + Pkg.name, targ).addObjects(["Queue.c"]);
}


======== Package.xdc ========
package collections [1,0,0]
{
	module Queue;
}


======== Queue.xdc ========
module Queue
{
instance:
	create();
	config UInt16 size = 32;
	Int8 Enqueue(UInt8 item);
	Int8 Dequeue(UInt8 * item);
	Int8 Peek(UInt8 * item);
	UInt16 Count();
	UInt16 Capacity();
	Void Clear();

internal:
	struct Instance_State
	{
		UInt8 buffer[];   /*! Buffer used to hold queued items */
		UInt16 capacity;	/*! Maximum number of items the queue can hold */
		UInt16 count;		/*! Number of items in the queue */
		UInt16 head;		/*! Index of head item in queue */
		UInt16 tail;		/*! Index of tail item in queue */
	};
}


======== Queue.c ========
#include "xdc/std.h"
#include "package/internal/Queue.xdc.h"

Int8 Queue_Enqueue(Queue_Object * obj, UInt8 item)
{
   if (obj->count == obj->capacity)
   {
      // Overflow occurred
      return (-1);
   }
   obj->buffer[obj->head] = item;
   obj->head++;
   if (obj->head == obj->capacity)
   {
      obj->head = 0;
   }
   obj->count++;
   return (0);
}

Int8 Queue_Dequeue(Queue_Object * obj, UInt8 * item)
{
   if (obj->count == 0)
   {
      // Queue is empty
      return (-1);
   }
   *item = obj->buffer[obj->tail];
   (obj->tail)++;
   if (obj->tail == obj->capacity)
   {
      obj->tail = 0;
   }
   obj->count--;
   return(0);
}

Int8 Queue_Peek(Queue_Object * obj, UInt8 * item)
{
   if (obj->count == 0)
   {
      // Queue is empty
      return (-1);
   }
   
   *item = obj->buffer[obj->tail];
   
   return(0);
}

UInt16 Queue_Count(Queue_Object * obj)
{
   return obj->count;
}

UInt16 Queue_Capacity(Queue_Object * obj)
{
	return obj->capacity;
}

Void Queue_Clear(Queue_Object * obj)
{
   obj->count = 0;
   obj->head  = 0;
   obj->tail  = 0;
}

Void Queue_Instance_init(Queue_Object * obj, const Queue_Params * params)
{
	obj->capacity = params->size;
	obj->count = 0;
	obj->head  = 0;
	obj->tail  = 0;
}


======== Queue.xs ========
function instance$static$init(obj, params)
{
	obj.buffer.length = params.size;
	obj.capacity      = params.size;
	obj.count = 0;
	obj.head  = 0;
	obj.tail  = 0;
}


Here is the code for my test application:

======== test/package.bld ========
var Build = xdc.useModule('xdc.bld.BuildEnvironment');
var Pkg = xdc.useModule('xdc.bld.PackageContents');
 
for each (var targ in Build.targets) {
    Pkg.addExecutable("prog", targ, targ.platform).addObjects(["prog.c"]);
}


======== test/package.xdc ========
requires collections;
package test {};


======== test/prog.cfg ========
var System = xdc.useModule('xdc.runtime.System');
var Program = xdc.useModule('xdc.cfg.Program'); 
var Q = xdc.useModule('collections.Queue');
Program.global["qInstStatic"] = Q.create({size:4});


======== test/prog.c ========
#include <xdc/runtime/System.h>
#include <xdc/cfg/global.h>
#include <Collections/Queue.h>
 
int main()
{
   UInt8 i;
   UInt8 sz = Queue_Capacity(qInstStatic);
   
   for (i = 0; i < sz; i++)
   {
      Queue_Enqueue(qInstStatic, i);
   }
   
   UInt8 item;
   for (i = 0; i < sz; i++)
   {
      Queue_Dequeue(qInstStatic, &item);
      System_printf("Item is %i\n", item);
   }
   
   return 0;
}


The MinGW and C64P targets build and run just fine, so hopefully I just missed something in the configuration. I have built against XDCTools 3.25.06.96 and 3.25.06.96 with the same results. Sorry for the code intense post.

Chris
Re: Trouble building for the GCArmv7A target [message #1449087 is a reply to message #1447658] Mon, 20 October 2014 22:38 Go to previous messageGo to next message
Alexei Colin is currently offline Alexei ColinFriend
Messages: 8
Registered: October 2013
Junior Member
IANE, but is the toolchain for Linux ABI appropriate for your case? Would arm-none-eabi-gcc be more appropriate than arm-linux-gnueabi-gcc? Not sure whether it is directly relevant, but XDC build for the v7A target provides its own C-runtime.

I successfully built your example (archive attached) for GCArmv7A with XDCTools v3.25.05.94 on Linux i686 host with arm-none-eabi-gcc 4.7.4 20130913 (from gcc-arm-none-eabi deb package), but not out-of-the box -- had to deal with the following issues. The following is almost certainly irrelevant to your case, but for benefit of Googlers that land on this thread.

1. *Problem*: warning about enums
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: warning: /home/acolin/rtml/src/ti/xdctools/xdctools_3_25_05_94/packages/gnu/targets/arm/rtsv7A/lib/gnu.targets.arm.rtsv7A.av7A(Assert.ov7A) uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail

*Fix*: This is due to an incompatibilty between the build environment which built the xdctool package binaries in the distribution and the compiler used to build the app and link the two. Fixed by rebuilding gnu/targets/arm/rtsv7A package with app's toolchain [*]. Ranted about this in a thread in TI-RTOS forum ("undefined reference to `atexit' in xdctools").

2. *Problem*: libc can't find _exit syscall
/usr/arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x2c): undefined reference to `_exit'

*Fix*: _exit syscall is defined in gnu/targets/arm/rtsv7A/syscalls.c but the corresponding object appears (within the linker script included via -T) before libc (-lc) on the linker cmd line, so linker doesn't look in syscalls.o. One fix is to add 'GCCTarget.lnkOpts.prefix = "-lc"' to config.bld. But it's probably not the right fix in light of this discussion.

3. *Problem*: libc can't find _sbrk syscall
/usr/arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0x18): undefined reference to `_sbrk'

*Fix*: this one is not defined in syscalls.c, so a pseudo-fix is to either define a sttub there and rebuild gnu/targets/arm/rtsv7A [*] or define a stub in the test app (e.g. prog.c): void _sbrk(int *inc) { (void)inc; }

4. *Problem*: .gnu.attributes section referenced in XDC's linker script doesn't exist
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: .gnu.attributes not found for insert

*Fix*: objdump on object files only shows .ARM.attributes but not .gnu.attributes (arm-none-eabi-gcc -v says 2.22). A workaround: edit gnu/targets/arm/linkcmd.xdt, change 'INSERT BEFORE .gnu.attributes' to .ARM.attributes: almost certainly the wrong thing to do, but removing the INSERT command won't work since that has a documented side-effect of disabling the default linker script.

[*] Issue when rebuilding gnu/targets/arm/rtsv7A:
*Problem*: Assembler doesn't like floating-point-unit-related instruction in boot.asm
boot.asm:115: Error: selected processor does not support ARM mode `fmxr fpexc,r0'

*Fix:* Edit gnu/targets/arm/GCArmv7A.xdc, add "-mfpu=vfp" to asm.opts. It's not clear why this field is marked readonly, which prevents from a cleaner fix of specifying this in config.bld like compiler options and linker options. Rebuild gnu/targets/arm with 'xdc all' and then rebuild gnu/targets/arm/rtsv7A with 'xdc clean && xdc all'.

[Updated on: Mon, 20 October 2014 22:51]

Report message to a moderator

Re: Trouble building for the GCArmv7A target [message #1449184 is a reply to message #1449087] Tue, 21 October 2014 02:17 Go to previous messageGo to next message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
Alexei,

Thank you for your fast response! This will be quite helpful as I will also need a bare metal implementation. Right now I am trying to develop applications that run under an embedded Linux OS on an ARM processor (e.g. Angstrom/Ubuntu on a BeagleBone). It shouldn't matter but I am developing my applications on a Windows machine and cross-compiling for arm-linux. Perhaps I am using the wrong target? GCArmv7A.xdc states that "This module defines an embedded target for Linux on Arm" and the os string is "Linux". This appears to be exactly what I want. It is my understanding that arm-none-eabi-gcc is used for bare metal targets and not for applications running under Linux. Do I need to rebuild the GCArmv7A module with my arm-linux-gnueabi-gcc toolchain?
Re: Trouble building for the GCArmv7A target [message #1449635 is a reply to message #1449184] Tue, 21 October 2014 16:42 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 114
Registered: July 2009
Senior Member
Chris,
here is the bug report for your initial problem: https://bugs.launchpad.net/gcc-linaro/+bug/1329080. We'll have a workaround for that problem in the next XDCtools release 3.30.05. Until then, you can do the following in your config.bld:
ARMLinux.profiles["release"].compileOpts.copts = "-O2 -ffunction-sections";
The target GCArmv7A is meant to be used in Linux environments, while all other targets in the gnu.targets.arm package that don't have the prefix 'GC' are for bare-metal environments.

As for the problem with .gnu.attributes referenced in the bare-metal target that Alexei mentioned above, that's most likely caused by mixing a bare-metal compiler with a Linux RTSC target that expects a Linux compiler.
Re: Trouble building for the GCArmv7A target [message #1452192 is a reply to message #1449635] Fri, 24 October 2014 23:22 Go to previous message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
Sasha,

This solves my problem. Thank you for your help.

Chris
Previous Topic:Assert strings populated in xdc.runtime.Text dispite being disabled
Next Topic:XDCTools 3.30: core distribution: which repository is x86 'target' package in?
Goto Forum:
  


Current Time: Sun Sep 23 01:20:40 GMT 2018

Powered by FUDForum. Page generated in 0.02475 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top