From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fd43431db0641948,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2004-03-09 07:01:35 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: ashpatelsmail@yahoo.co.uk (Ash)
Newsgroups: comp.lang.ada
Subject: ada multi -vx works 32 mb address limit
Date: 9 Mar 2004 07:01:35 -0800
Organization: http://groups.google.com
Message-ID: <14406c40.0403090701.79642271@posting.google.com>
NNTP-Posting-Host: 53.122.197.194
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1078844495 6809 127.0.0.1 (9 Mar 2004 15:01:35
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 9 Mar 2004 15:01:35 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:6189
Date: 2004-03-09T07:01:35-08:00
List-Id: <comp.lang.ada>

Hi 
problems with the 32 mb relative addressing limit using
vxworks/tornado are well documented in the vxworks group here, however
most solutions posted give the solution as using the option -mlongcall
but this ojnly appears to be valid for the Gnu ada/c compilers.
Does anybody have a solution for this relative addressing problem
using adamulti -
i've seen other suggestions such as 


verbatim copy from John posted 2003-03-12
"
2) Link your code with the kernel (as long as the resulting text
segment is less than 32MB in size, this will work well).

3) Configure your system to have 64MB of memory, but assign 32MB of it
to the USER_RESERVED_MEM region. Boot, load the dynamically loaded
modules, and then add the user resevered memory region to the main
system pool using memAddToPool().

4) This one is a little more complex, but should still be workable:
for each of your resulting .o files, determine the external references
that they need. Rename these undefineds (IIRC, objcopyppc will be able
to help you here). Then, create a stub that defines the new symbol,
and makes a 32 bit range call to the original. The most efficient way
of doing this would be in assembler, but you could, if you like, write
it in C and compile with the -mlongcall option mentioned in (1) above.

"

i am unsure as to which of these is the best option for me - in this
option 2 is out of the question

any assistance would be greatly appreciated 

Ash