[ale] Re: [ECOS] g++ problem resolving '__builtin_delete' in cross compilation/linkage

[Jonathan Larmour]

In article <FD7521AABD30D2118284006008AE0B6E03BF8E at ns1.tga.com> you write:
>
>I built a partial set of ecosSWtools-990319 targeting the SH-2 from a
>Linux/RH6.0 installation which appears to compile and link properly for
>simple 'C' source

Be warned ecosSWtools-990319 is based on a now relatively old toolchain.
We made no attempt to check validity for targets other than the eCos
supported ones. We added lots of updates to the toolchain for our supported
targets which may have broken other targets.

It may be better to switch to egcs, which will also mean you can pick the
brains of people on the egcs list.

>Moving to 'C++', I also get executables which map
>properly to my target board, and better yet, produce debug data sufficient
>for an Hitachi debugger to step through the code from source level.
>
>When I link, I have an undefined reference to '__builtin_delete' at exit
>where the C++ object is deleted. (I have no actual destructor nor
>dynamically allocated storage for the simple example.)

This is meant to come from libgcc. Do a sh-elf-nm of (I think)
<tooldir>/lib/gcc-lib/sh-elf/libgcc.a and look to see if it is defined
in there. If so, check that you are definitely linking in libgcc, which
is the default unless you pass -nostdlib. If it's not there, it's probably
a problem with the toolchain.

>If I simply edit the
>assembly language and remove the call to '__builtin_delete' the code links
>and runs fine.

Or you could provide a dummy definition. From memory:

void operator delete (void *ptr) throw () {}
void operator delete[] (void *ptr) throw () {}

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault