Protection for Ada Binary Libraries

Protection for Ada Binary Libraries

[Edward Berard]

I find myself dealing with increasing numbers of clients who are
considering the use of Ada technology for commercial (non-weapons
systems, and often non-government) applications. Often questions arise
which would never even be considered in the embedded real-time arena.
What follows is one of those questions.

Suppose one is developing an Ada product which is to be used by Ada
software engineers. Part of this product involves a library of Ada
packages. The developer wishes to make the package specifications
available to his or her clients, but wishes to protect the bodies of
these same packages. The mechanism the developer chooses is to create
a "binary" Ada library using the library mechanisms provided by Ada
development system vendors. (For example, on the DEC VAX the developer
will use DEC's Ada library mechanism, and on a Sun Workstation the
developer will supply several libraries, e.g., one for the TeleSoft
compiler, one for the Verdix compiler, one for the Alsys compiler, and
one for the Tartan Labs compiler.)

Everything appears to be in order until the developer discovers that
by using the symbolic debugger supplied in some of these environments,
a client can have access to all the source code for the bodies to the
packages. Before I advise this client on what I feel is the obvious
answer, I need to make sure that what I am saying is accurate.
Specifically, I need answers to the following questions:

   1. When compiling Ada source code into a library, do most, if not
      all, Ada compilers have some mechanism (e.g., a /NO DEBUG
      switch) which will prevent the source (and even close
      approximations of the original source) from being placed in the
      library?

   2. Assuming one can prevent the original Ada source code from
      becoming part of the library, are there any obvious (or subtle)
      disadvantages to this with some Ada compilers?

   3. Are there other commonly accepted mechanisms for protecting
      source code in Ada libraries?

   4. Given that a developer wishes to make binary libraries of Ada
      packages available to potential clients, are there better
      mechanisms than tying the libraries to specific Ada development
      system?

				-- Ed Berard
				   eberard@ajpo.sei.cmu.edu
				   (301) 695-6960

Re: Protection for Ada Binary Libraries

[offer]

There are three different issues in your question:

1. Most compilers, and in particular, those that use DIANA, have a
mechanism to not include the source (or some form of internal
representation of the source) in the program library, the reasons
being: reducing the size of those libraries and keeping bodies' source
code proprietary (e.g. the implementation of TEXT_IO). The disadvantage
is clearly the inability the see the source at debug time and also
the inability to provide pretty-printing/interspersed source/assembly
listings.

2. Most compilers, today, support hierarchical library structure. By
protecting part of the library, one can inhibit read access to
certain data in this part (this is both a program library manager and
a debugger functionality). A vendor may put the spec in one library
and the body in another and protect the later.

3. About a binary interface to a reusable component. The only way
to do it without the need to recompile for each compiler, is to agree
on standard binary interface (calling sequence, data reps, etc). The
compiler can then support it via pragma INTERFACE. I believe as more
and more similar requirements appear, those standards will emerge.

Offer Pazy
Intermetrics, Inc.
Cambridge, MA
(617) 661-1840

Re: Protection for Ada Binary Libraries

[Barnacle Wes]

In article <57900063@ada-uts>, offer@ada-uts writes:
> 1. Most compilers, and in particular, those that use DIANA, have a
> mechanism to not include the source (or some form of internal
> representation of the source) in the program library, the reasons
> being: reducing the size of those libraries and keeping bodies' source
> code proprietary (e.g. the implementation of TEXT_IO). The disadvantage
> is clearly the inability the see the source at debug time and also
> the inability to provide pretty-printing/interspersed source/assembly
> listings.

DEC really has this down pat in the VAX/Ada compiler.  They have the source
for the Ada interfaces to the Ada RTL available any time you are in ACS.
The source for the libraries themselves are an entirely different manner.
The libraries aren't even written in Ada; the Ada bindings are IMPORT
PRAGMAS to link to the Bliss calling sequences.  The libraries (I would
assume) are written in Bliss-32.  Remember:  "Bliss is ignorance!"  (Terry
Lambert).

-- 
    /\              - " Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!utah-gr!
  /    \/ \/\/  \   -   Contend in Vain."   -  uplherc!sp7040!
 / U i n T e c h \  -        Schiller       -     obie!wes

Re: Protection for Ada Binary Libraries

[Arny B. Engelson]

In article <324@ajpo.sei.cmu.edu>, eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
> Suppose one is developing an Ada product which is to be used by Ada
> software engineers. Part of this product involves a library of Ada
> packages. The developer wishes to make the package specifications
> available to his or her clients, but wishes to protect the bodies of
> these same packages. The mechanism the developer chooses is to create
> a "binary" Ada library using the library mechanisms provided by Ada
> development system vendors. (For example, on the DEC VAX the developer
> will use DEC's Ada library mechanism, and on a Sun Workstation the
> developer will supply several libraries, e.g., one for the TeleSoft
> compiler, one for the Verdix compiler, one for the Alsys compiler, and
> one for the Tartan Labs compiler.)
 
> Everything appears to be in order until the developer discovers that
> by using the symbolic debugger supplied in some of these environments,
> a client can have access to all the source code for the bodies to the
> packages.
> 				-- Ed Berard



I am currently faced with a similar problem.  My (current) solution (using
DEC's VAX Ada) is to simply delete the .ADC (the copied source) files from
the Ada library for those units that the user doesn't need to see.  The user
can still compile and link his/her own units with mine, but when the symbolic
debugger is invoked, it only displays the source code for the user's units.
I suppose a really resourceful person may be able to extract more information
from the intermediate code files, but for my situation this is sufficient.


  - Arny Engelson
  {ihnp4,clyde}!wayback!arny

Re: Protection for Ada Binary Libraries

[Ada Bozo]

I have recently faced a similar problem that I have only partially solved with
VAX Ada. Suppose that one wanted to provide a "subsystem" of packages to a
client where only a small set (perhaps only one) of the packages is "visible"
to the client. Such things as graphics support routines, database management
routines, and, even, the CAIS come to mind. Normal delivery of source code
to be compiled into the client's program library is out of the question. Can
the VAX Ada compiler and Ada Compilation System (ACS) provide any help?

My (partial) solution: tell VAX Ada to create a partially linked object module
containing the internal view of the subsystem via "ACS EXPORT" (making VAX Ada
think that the module will be called by a non-Ada program), and then compile
a "shell" of the subsystem and install the body of the previously linked
object (making VAX Ada think it is "importing" a non-Ada program). Thus, the
client can compile against the source code of the shell while linking against
the object code of the body. Example:

	package INTERNAL is
	   procedure INTERFACE;
	   pragma export_procedure (INTERFACE, "XXX_INTERFACE");
	end INTERNAL;
	package body INTERNAL is
	   procedure INTERFACE is
	   begin ... end INTERFACE;
	end INTERNAL;

$ ADA INTERNAL
$ ACS EXPORT INTERNAL

	package EXTERNAL is
	   procedure INTERFACE;
	   pragma interface (INTERFACE, ADA);
	   pragma import_procedure (INTERFACE, "XXX_INTERFACE");
	end EXTERNAL;

$ ADA EXTERNAL
$ ACS LINK EXTERNAL INTERNAL

This last command provides a mechanism to link against a specified object
file. (Yes, I know that I can also "install" the object file as the body
of the shell package EXTERNAL but I'm at home without my VAX Ada RM.) The
problem with this approach is two-fold. First, I (as developer) must maintain
two versions (INTERNAL and EXTERNAL) of the same interface. Second, the
VAX/VMS linker complains about "multiple definitions" because the first
(partial) link brings in many Ada pieces that are also brought in during
the second link. However, it appears that I can now ship the EXTERNAL
definition and the INTERNAL object file without requiring either the 
full source code or, for that matter, the Ada program library with all of
the internal symbol tables and object files to be shipped to the client.

Has anyone else tried this approach using VAX Ada and the ACS? Are there
better solutions using the ACS and/or the VAX/VMS linker? I don't have any
experience with other vendor library/linker mechanisms to know if this
approach works but clearly I am becoming VAX Ada dependent by using the
pragmas "import_procedure" and "export_procedure". However, sometimes
pragmatics must outweigh concerns for compilation system independence.

Daryl Winters
(603) 885-9226

uucp: decvax!savax!winters
arpa: winters@ajpo.sei.cmu.edu