eberard@ajpo.sei.cmu.edu (Edward Berard) (02/19/88)
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-6960offer@ada-uts (02/21/88)
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
arny@wayback.UUCP (Arny B. Engelson) (02/23/88)
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
winters@savax.UUCP (Ada Bozo) (02/25/88)
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
wes@wsccs.UUCP (Barnacle Wes) (03/04/88)
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