gnat/rtems,gnat3.12p,gcc2.8.1,hello_world_ada

[lange92 at 2067.resnet.uni.edu]

My apologies for the re-post, but apparently my mailserver was down the
morning following this message being sent, and the mailing list on
oarcorp.com doesn't seem to have August 2001 logs viewable yet.

I've tried modifying the Makefile and removing the -O and -O4 options,
removing optimizations (hopefully.) I also removed the -g options that
make it compile in all the debugging symbol information, but it seems to
do that anyway (a default on the crosscompiler i386-rtems-gcc?)

I've also attempted to compile the hello_world_ada example program by
hand, one step at a time. I modified the init.c file to include calls to
adainit, adafinal, and __gnat_initialize and __gnat_finalize, and receive
"implicit declaration of function" warnings for these symbols. But since
init.c is compiled before the hello.adb file, that is to be expected--I think.
But do I need to provide `extern int __gnat_initialize ();' lines for each
of these calls in the init.c file, as the call to gnat_main (now
_ada_main) is provided in the original init.c file?

Is there a simple way to get a definitive list of the symbols in the
binary? I'm a novice when it comes to gdb--and I don't believe gdb has
been built on my system yet--at least, not the rtems-aware gdb.

I have attempted all this with the pc386 bsp. I don't know where exactly
the primary dependency is on COFF, but I'm interested in migrating
the whole system to ELF, in the interests of getting a halfway up-to-date
system.

Is there some reference program, or a comprehensive file format reference
I can use to verify that the files are in the correct format? Best I know
to do right now is use the `file` command, and it produces the following:

hello.o: 80386 COFF executable not stripped - version 30821
b~hello.o: 80386 COFF executable not stripped - version 30821
init.o: 80386 COFF executable not stripped - version 30821
hello: 80386 COFF executable not stripped

Of course, I am aware that file only uses a system for checking file
headers to determine the file format, but that doesn't necessarily verify
the consistency of the files (the same results are to be had if I build
against the pc486 bsp [still configured as ELF] and use i386-rtems-* [the
ELF tools].) I'm guessing here, but based on the way the output and the
bsp_specs files read, it would suggest that a header is simply tacked on
after the compilation--and that would fool the file utility.

Thanks in advance.

DanL

On Mon, 6 Aug 2001, Joel Sherrill wrote:

> lange92 at 2067.resnet.uni.edu wrote:
> >
> >   I also have not figured out the use of "-n" and where to put a reference
> > to call "adafinal", as Joel pointed out in a previous message.
>
> You should call it once ada_main returns to do cleanup before exitting
> the application.

A second attempt with lilo and the pc486 bsp (once as ELF, once as COFF)
simply appeared to freeze the computer. This brings up the possibility
that the main procedure in hello.adb is not actually executing at all.

Does the init routine control execution of the ada program?

If it does, I may have found a relevant section in the gnat-3.12p User
Guide. It refers to a package called P, and talks of using the "gcc -c"
option in the surrounding text. From the text (edited for brevity and
readability):

"
__gnat_initialize ();
adainit();

_ada_m ();

adafinal();
__gnat_finalize ();

exit (gnat_exit_status);

The call to __gnat_initialize and the corresponding call at the end of
execution to __gnat_finalize allow any specialized initialization and
finalization code to be hooked in. The default versions of these routines
do nothing.

The call to m is the call to the main program."

Now, I see no obvious connection between the _ada_main that init.c has,
and this mysterious _ada_m that is mentioned in the user guide. Is it
possible that we call the initialization/finalization routines, but
somehow avoid execution of the actual executable code in the ada file?

Thoughts and insight are welcomed in finding the cause of the problem
here. Thanks again.

DanL