ld relocation error ???

David Leviner

unread,

Jul 22, 1999, 3:00:00 AM7/22/99

to

Has anyone seen this error?

"Relocation value does not fit in 24 bits.
ld error: error reading file (errno = 0x3d0001)."

If so what was your work-around.
I am writing a driver for an analog I/O PMC board.
This driver compiles, loads, and works fine
under mv1603, mv1604, mv2304, mv2603, mv2604,
pcore604, and jtt686 BSP's but does not load under
mv2700 BSP.

I am using Tornado 2 on NTxPowerPC.

Best Regards,
David

____________________________
David Leviner
Sr. Real Time Software Engineer
Chandler/May, Inc.
(256) 722-0175
david....@chandlermay.com

Cameron Fowler

unread,

Jul 22, 1999, 3:00:00 AM7/22/99

to

I am assuming your mv2700 has more than 32 Mb of memory.

this basically stems from the fact that the branch and link instruction
only has 25 bits for address space (typo in the error message for
24 i believe.)

Basically you have two options. set USER_RESERVED_MEM
to take up all but 32 Mb. Then download your modules, and then
use memAddToPool to add the rest of your memory. This has been
the old tried and true method for quite awhile.

Also, Wind River has a patch that allows you to compile using a
different branch instruction (I'm at home or I would give you more
details) the performance hit however is about 6 cycles per branch
instead of 1.

David Leviner wrote in message <7n7chk$2b...@overload.lbl.gov>...

bwa...@cspi.com

unread,

Jul 23, 1999, 3:00:00 AM7/23/99

to

David,
This error is due to the fact that you have more than 32 MB of memory.
There is a compilier patch for Tornado 1.0.1 patch SPR #22767 which
addresses this exact problem. Here is an excerpt from the SPR
documentation:

Normally the compiler produces single-instruction, 26 bit, direct
calls. In order to access functions that may lie anywhere in the
32 bit address space we need to call through a function pointer.
Because indirect calls are more expensive we would like to make
direct calls wherever possible. With `-mlongcall' the compiler
uses a conservative heuristic to decide whether to make a direct
(26) call or an indirect (32 bit) call: it generates a direct call
if the target function is non public; or if its definition has
already been seen; or if it is declared with the attribute
"shortcall" (*Note Function Attributes::). Otherwise it generates
an indirect call. An underlying assumption is that individual
translation units span less than 32MB so that it is always safe to
make direct calls to functions in the same module.

This '-mlongcall' patch has been incorporated into Tornado 2.0. All you
need to do is add '-mlongcall' to your c flags and you should be able to
recompile and load your program. I have done some testing and it seems to
work fine under Tornado 2.0.
Another workaround, although crude is to allocate a large block of memory
from the shell (to reduce the available memory below 32 MB), load your
application, and free the memory before spawning your program. I have used
both of these methods for testing. The second, crude method, works very
well when using 3rd party applications that were not built with the long
call switch, but I would reccommend using the switch if you are able to
recompile
the application.

Good Luck
Brian Waite
CSPI Customer Support
Email: bwa...@cspi.com

vxwe...@lbl.gov on 07/22/99 10:42:51 AM

To: vxwork...@csg.lbl.gov
cc: (bcc: Brian Waite/CSP)
Subject: ld relocation error ???

Submitted-by owner-vxwexplo-process Thu Jul 22 07:42:45 1999
Submitted-by: David Leviner <david....@chandlermay.com>

Douglas Fraser

unread,

Jul 23, 1999, 3:00:00 AM7/23/99

to

You can also set aside a reserved memory chunk using
USER_RESERVED_MEM in config.h. It comes right of the top.
When you are done loading, you can return that reserved
chunk with memPartAdd().

Charlie Grames has alluded to problems with sysPhysMemTop()
when you do this, and you have to patch the BSP to get
around that. (it always reports the initial top) Chances
are that your code doesn't really need this. This is the
method we use to support dynamic linking in 64MB of MPC860
memory. Technically, I am no longer there, now working on
ARM architecture products, which carries its own baggage.

Good luck
Doug

bwa...@cspi.com wrote:
>
> David,
> This error is due to the fact that you have more than 32 MB of memory.

Mark Muri

unread,

Jul 23, 1999, 3:00:00 AM7/23/99

to

--============_-1279364686==_ma============
Content-Type: text/plain; charset="us-ascii"

At 8:50 AM -0700 7/23/99, the vxWorks Users Group Exploder wrote:
>Submitted-by owner-vxwexplo-process Fri Jul 23 08:50:49 1999
>Submitted-by: bwa...@cspi.com

>
>
>David,
> This error is due to the fact that you have more than 32 MB of memory.

>There is a compilier patch for Tornado 1.0.1 patch SPR #22767 which
>addresses this exact problem. Here is an excerpt from the SPR
>documentation:
>

It was our understanding that this patch, however, did not correct all
26-bit references. Specifically, any code generated on the behalf of C++
static constructors & destructors still had the problem. Obviously, if
*all* of the code cannot be clean of 26-bit references, *none* of it can be
loaded (easily).

We have used similar tricks to force code loads into the lower 32MB of
memory. This problem is the source of a lot of frustration for my user
community!

At 8:50 AM -0700 7/23/99, the vxWorks Users Group Exploder wrote:

>Submitted-by owner-vxwexplo-process Fri Jul 23 08:50:49 1999

>Submitted-by: bwa...@cspi.com

>

>David,

> This error is due to the fact that you have more than 32 MB of
memory.

>There is a compilier patch for Tornado 1.0.1 patch SPR #22767 which

>addresses this exact problem. Here is an excerpt from the SPR

>documentation:

>

It was our understanding that this patch, however, did not correct
<bold><underline>all</underline></bold> 26-bit references.
Specifically, any code generated on the behalf of C++ static
constructors & destructors still had the problem. Obviously, if *all*
of the code cannot be clean of 26-bit references, *none* of it can be
loaded (easily).

We have used similar tricks to force code loads into the lower 32MB of
memory. This problem is the source of a lot of frustration for my user
community!

Mark

*==========================o=========================================*

| Mark E. Muri | http://home.san.rr.com/themuris |

| @Work | E-Mail: mailto:mm...@qualcomm.com |

| Sr. Staff Engineer/Mgr | Phone: (619) 658-3303 |

| QUALCOMM, Inc | Fax: (619) 845-5065 |

| Mail Stop: AI-107E | Pager: (619) 636-0446 |

| 6262 Lusk Blvd. | Alpha: mailto:mm...@pager.qualcomm.com *

| San Diego, CA 92121

| @Home | E-Mail: mailto:mark...@san.rr.com *

| 9556 Hiker Hill Rd. | Phone: (619) 484-1075 |

| San Diego, CA 92129 | Cell: (619) 889-6591 (Mark) |

| | Cell: (619) 254-4595 (Lydia) |

| | Pager: (619) 654-7075 (Lydia) |

*==========================o=========================================*

--============_-1279364686==_ma============--

Charlie Grames

unread,

Jul 23, 1999, 3:00:00 AM7/23/99

to

Actually, 26 bits. The branch value is signed, so its range is really
+/-32 MB. The "+" part is of greatest concern when loading since
VxWorks typically resides in low memory and user applications are
typically loaded in high memory.

The "24 bits" message is misleading, but correct. The two
least-significant bits of the 26-bit offset are always assumed to be
zero (because instructions are always four-byte bounded), so only 24
bits contain meaningful information (and, in fact, the two bits in the
instruction are used for something else). This is defined by the
PowerPC ABI, not Wind River.

Charlie Grames
The Boeing Company
Charles.R.Grames @ boeing.com

Simon Roberts

unread,

Jul 26, 1999, 3:00:00 AM7/26/99

to

Seems that there are alot of us out there bumping into this old chestnut!

We are working with a MVME2400 with 64MB and in summary here are the changes I made which appear to work:

In config.h:

<snip>
/*
* Local Memory definitions
*
* By default, the available DRAM memory is sized at bootup (LOCAL_MEM_AUTOSIZE
* is defined). If auto-sizing is not selected, make certain that
* LOCAL_MEM_SIZE is set to the actual amount of memory on the board.
* By default, it is set to the minimum memory configuration: 16 MB.
* Failure to do so can cause unpredictable system behavior!
*/

/* SCR changed 23/7/99 */
/* #define LOCAL_MEM_AUTOSIZE */ /* undef for fixed size */
#undef LOCAL_MEM_AUTOSIZE /* define for auto size */

#define LOCAL_MEM_LOCAL_ADRS 0x00000000 /* fixed at zero */

/* SCR changed 23/7/99 */
/* #define LOCAL_MEM_SIZE 0x02000000 */ /* Default: Min memory: 32MB */
#define LOCAL_MEM_SIZE 0x04000000 /* Default: Min memory: 64MB */

#define RAM_HIGH_ADRS 0x00200000 /* RAM address for ROM boot */
#define RAM_LOW_ADRS 0x00100000 /* RAM address for kernel */

/* user reserved memory, see sysMemTop() */

/* SCR changed 23/7/99 */
/* #define USER_RESERVED_MEM (0) */ /* number of reserved bytes */
#define USER_RESERVED_MEM (0x02000000) /* number of reserved bytes */
<snip>

Then at startup issue the following command to reinstate the reserved memory with the system memory pool:

memAddToPool (sysMemTop(), 0x2000000)

That about sums it up from our point of view. I must say that I am extremely reluctant to use the alternative solution (i.e. compiling with the -mlongcall option set) as there are caveats galore in the WRS patch resolution (SPR 25893), notably:

"Code complied with -mlongcall will be larger and slower."
"... violates the current EABI standards."
"... not been extensively tested by WRS ..."
"... WRS does not encourage the user of the -mlongcall option."

Regards,
Simon Roberts.