Unsupported .stab relocation error / mlongcall issue

Unsupported .stab relocation error / mlongcall issue

[Fabien]

Hi,

We are developping an Ada95 application using the GNAT 5.01a compiler
for PowerPC, running on a Motorola 5100 card, with VxWorks 5.5.1.
The application is rather big therefore we compile using the -mlongcall
option (no other options).

We observe that the complete system has an unstable behaviour: it gets
stack. We get some references to "Unsupported .stab relocation" error.
We didn't find any piece of code in our application that may overwrite
the O.S. memory (we do dynamic memory allocation only at startup time),
that may have uninitialized variables...
The same application compiled for Windows 2000 seems to behave
properly.

Is there some known issues regarding the compiler and long call jumps
under VxWorks?
Do we need to recompile the Ada Libraries with the -mlongcall option?
If yes, how?

Does anyone have any idea on what could possibly raise an "Unsupported
.stab relocation error"?

Thanks in advance,
Best Regards,
Fabien.

Re: Unsupported .stab relocation error / mlongcall issue

[Jeffrey R. Carter]

Fabien wrote:

> We are developping an Ada95 application using the GNAT 5.01a compiler
> for PowerPC, running on a Motorola 5100 card, with VxWorks 5.5.1.
> The application is rather big therefore we compile using the -mlongcall
> option (no other options).

If you're using GNAT 5.01a, presumably you have a support contract with AdaCore, 
and they should probably be the 1st place you should ask.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15

Re: Unsupported .stab relocation error / mlongcall issue

[Simon Wright]

"Fabien" <fabien_milcent@yahoo.fr> writes:

> We are developping an Ada95 application using the GNAT 5.01a compiler
> for PowerPC, running on a Motorola 5100 card, with VxWorks 5.5.1.
> The application is rather big therefore we compile using the -mlongcall
> option (no other options).

We are in a similar position.

Personally I would consider upgrading; 5.01 is early technology. No
experience of 5.03a1 yet, if to 5.02a1 you should stick to -O1 for
this target, not -O2 (see the Known Problems on the AdaCore site).

> We observe that the complete system has an unstable behaviour: it gets
> stack. We get some references to "Unsupported .stab relocation" error.

'gets stack'??? don't understand. You do have to be careful with task
(and main program!) stack sizes, there's a VxWorks command checkStack
(maybe stackCheck) that may be useful.

There is a GCC option -fstack-check (and some interactions with the
GNAT options for variable initialization, at any rate up to 5.02a1
AFAICR). Not recommended (by me) if you're writing code to be called
back from VxWorks tasks.

> We didn't find any piece of code in our application that may overwrite
> the O.S. memory (we do dynamic memory allocation only at startup time),
> that may have uninitialized variables...
> The same application compiled for Windows 2000 seems to behave
> properly.

We had problems where allocated store was initialized to 0 under
Windows but left random on VxWorks. There are GNAT options to
initialize variables to invalid values (-gnatVx, I think), but they
have proved a bit flakey for us (I _think_ this was 5.02a1), so I made
a storage pool that initializes with 16#deadbeef# -- if you are
interested see ColdFrame.{Bounded,Unbounded}.Storage_Pools in
http://coldframe.sourceforge.net .

> Is there some known issues regarding the compiler and long call jumps
> under VxWorks?

Not that I know of.

> Do we need to recompile the Ada Libraries with the -mlongcall option?
> If yes, how?

I think they already are. If you look in the library .ali files you
should see the compilation options used near the top.

If you need to recompile the libraries, start with
.../adalib/Makefile.adalib (but I think you will have to do some work
on it for 5.01!)

> Does anyone have any idea on what could possibly raise an "Unsupported
> .stab relocation error"?

New to me!


As someone else has said, you ought to have an AdaCore support
contract for that compiler. Advice from us is all very well, but you
will get an authoritative answer from them!