GNAT 3.10p OS/2 Assert/Library bug?

GNAT 3.10p OS/2 Assert/Library bug?

[Steve Whalen]

First, I really appreciate what ACT does for Ada95 and I really like
the GNAT compilers, so...

Since I'm NOT a paying customer of ACT (yet!), I try to avoid wasting
their time and try to be as self reliant as possible (I actually RTFM,
etc.), but I've run across what appears to be a genuine (but obscure)
bug.

If there is any way I can look up this bug in ACT's bug list myself to
see if they already know about it, please let me know because I'd be
happy to do that. But so far I haven't figured out a way to do so (and
haven't seen this particular bug mentioned on CLA or on GNAT / Chat).

If it's NOT possible for me to look this up in ACT's bug list, then I
would like to get input from the folks on CLA regarding what appears
to be a bug in GNAT 3.10p for OS/2 - emx (and also GNAT 3.07 for MsDos
- DJGPP) (but which is NOT visible in GNAT 3.10p Linux, etc.).  I
don't want to report it if it's already known, because I presume it
would take ACT "some" amount of time to figure out they already know
about it, or it's already fixed in an upcoming release, etc.


===> Bug Summary (example source code at end of message) <===

Symptom: gnatmake blows up with "undefined symbol" error if you:

1) are running GNAT 3.10p OS/2 - emx (or GNAT 3.07 MsDos - DJGPP)

2) create a package / library file (.o and .ali) that has a pragma
Assert in it, but compile with Asserts disabled (no -gnata), as you
would when you finishing testing and put the package into your library
directory for re-use.

3) later, you compile a program with assertions enabled (-gnata) AND
with the package from step 2.  The link step will fail with one or
more "undefined symbol" errors.

(i.e. you're mixing a pre-compiled package that had a pragma Assert in
it, but was compiled with assertions disabled, with a program
containing a pragma Assert, and trying to compile the new program with
assertions enabled (-gnata) while using the pre-compiled package).


===> Workaround <===

Use "ar" to add EVERY .o file in system adalib directory to the gnat.a
library file distributed with GNAT OS/2.  That way, when GNAT fails to
list the s-assert.o file (along with a couple of others) in it's
explicit .o link list (in b_xxxxx.c), the linker finds them in the
gnat.a library anyway.  This seems to work for me (I hope I'm not
creating some other, even more obscure problem by doing this...).

I suspect this bug may not have been noticed before, because on most
machines GNAT does NOT appear to produce an explicit list of all the
.o files to include in the link step (i.e. in the b_xxxxxx.c file it
generates).  I suspect that if the other platforms produced such a
list, it would be wrong too, under these circumstances.

Anyway, this pragma Assert situation, seems to confuse GNAT (GnatBind
/ BindGen? / ALI table build flag setting?).

Since running into this has made me think about it, I realized I don't
even know (and can't tell from the GNAT user guide) whether or not
using the -gnata flag when compiling a program *should* enable the
pragma Asserts that may be "hiding" in modules already in the re-use
library that were compiled with assert/debug DISabled.  I personally
think they should remain DISabled...

GNAT should probably do something a bit more elegant than creating the
"undefined symbol" problem.  And I don't think this qualifies as a
"side affect" of the pragma Assert, at least in the usual sense, as
mentioned in the documentation.


===>  sample code and test run <===

FIRST ===>

gnatmake -c testpack
gcc -c testpack.ads

--------TestPack.ads---------------------

package TestPack is
   type Small_Record is
      record
         s1 : Integer;
         s2 : Integer;
      end record;
   type Big_Record is
      record
         b1 : Integer;
         b2 : Integer;
         b3 : Integer;
         b4 : Integer;
      end record;
   pragma Assert (Big_Record'Size =
	          2 * Small_Record'Size);
end TestPack;

-----------------------------------------

THEN ===>

gnatmake -gnata testprog
gcc -c -gnata testprog.adb
gnatbind -x testprog.ali
gnatlink testprog.ali

----------TestProg.adb-------------------

with TestPack;
procedure TestProg is
   b : TestPack.Big_Record;
   s : TestPack.Small_Record;
begin
   b.b1 := 1;
   s.s1 := 2;
   pragma Assert (b.b1 = s.s1);
end TestProg;

-----------------------------------------


RESULT ===>

under GNAT 3.10p OS/2 - emx 
  and GNAT 3.07 MsDos - DJGPP

GNATLINK 3.10p (970814) Copyright 1996 Free Software Foundation, Inc.
gcc -c b_testprog.c
gcc b_testprog.o e:/emx/gnatlib\system.o e:/emx/gnatlib\s-tasoli.o 
(continued) e:/emx/gnatlib\s-taspda.o e:/emx/gnatlib\s-stalib.o 
(continued) ./testpack.o ./testprog.o -L./ -Le:/emx/gnatlib\ 
(continued) -L\ -lgnat -lgnat -o testprog.exe

./testprog.o: Undefined symbol 
(continued) _system__assertions__raise_assert_failure referenced 
(continued) from text segment

gnatmake: *** link failed.


under GNAT 3.10p Linux (compile OK, runs correctly):

./testprog

raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : testprog.adb:8

-----------the end-----------------------




-- 
{===----------------------------------------------------------------------===}
                    Steve Whalen     swhalen@netcom.com
{===----------------------------------------------------------------------===}

Re: GNAT 3.10p OS/2 Assert/Library bug?

[Robert Dewar]

Steve Whalen asks

<<If there is any way I can look up this bug in ACT's bug list myself to
  see if they already know about it, please let me know because I'd be
  happy to do that. But so far I haven't figured out a way to do so (and
  haven't seen this particular bug mentioned on CLA or on GNAT / Chat).>>

We do not publish such a list. A major reason for not publishing it is
that our experience is that in virtually 100% of cases, when people think
they have a bug that is the same as one in the list, they are wrong. The
trouble is that many bugs correspond to very special sets of circumstances,
and of course you don't know what these are before you fix it (often you
don't even know after you fixed it). So the attempt to identify a bug with
something on the list *does* waste time, both for the submitter and for
us (since it is almost never useful).

<<If it's NOT possible for me to look this up in ACT's bug list, then I
  would like to get input from the folks on CLA regarding what appears
  to be a bug in GNAT 3.10p for OS/2 - emx (and also GNAT 3.07 for MsDos
  - DJGPP) (but which is NOT visible in GNAT 3.10p Linux, etc.).  I
  don't want to report it if it's already known, because I presume it
  would take ACT "some" amount of time to figure out they already know
  about it, or it's already fixed in an upcoming release, etc.>>

You should report it. Only we can tell if it's already known, and often
even we won't be able to see that it is related to another bug. We are
happy to get bug reports from unsupported users, and we certainly do not
regard such reports as a waste of time. Eventually all such reports are
looked at, and one encouraging aspect of GNAT is that even as the number
of users is going up, the number of open bug reports is steadily 
decreasing, including those reported by unsupported users.

What you are more likely to do if you post GNAT bug reports on CLA is
to waste the time of CLA readers, virtually none of whom are going to
take the time to examine a bug report of this kind. If you think you
have a bug report, send it along to report@gnat.com!

Note that we never take bug reports from CLA, there is no easy way for
us to do this, so please forward this report to the proper address.

Robert Dewar
Ada Core Technologies

Re: GNAT 3.10p OS/2 Assert/Library bug?

[Steve Whalen]

OK, I'll submit the bug report. 

Thanks again for the great work on GNAT


-- 
{===----------------------------------------------------------------------===}
                    Steve Whalen     swhalen@netcom.com
{===----------------------------------------------------------------------===}