X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10112201703.AA18384@clio.rice.edu>
Subject: Re: RFC - Dynamic loading
To: djgpp-workers AT delorie DOT com
Date: Thu, 20 Dec 2001 11:03:48 -0600 (CST)
In-Reply-To: <3C220BB0.3291C3EC@is.elta.co.il> from "Eli Zaretskii" at Dec 20, 2001 06:02:56 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > Symbols would not be available, as is today.
> 
> Today DXEs are not used for user code.  If we introduce a less restricted 
> facility, this will probably no longer be true, so users will need to debug 
> dynamically-loaded code.

I agree this may create a new problem - but I don't want to abandon the
new features which are simple to provide because the new support features
require 10X the development time.

> > Don't build it into a DXE until you've debugged it?
> 
> IMHO, that is not a very good alternative.  E.g., imagine a DLL 
> written by someone else.

It would be similar today to debugging a stripped EXE image.  If you
wanted to debug it, you should build from source and link to objects.

> > The only potentially debuggable alternative I saw was to build on the
> > XCOFF support for windows PE type DLLs
> 
> Why do we need special support for that?  Can't we use one of the GDB 
> tricks, whereby it sets a breakpoint in dlopen and waits until the 
> library is actually loaded?

I am not familiar with the GDB tricks.  I was not planning on providing
the dlopen interface initially, since it requires lots of text symbol
names that I would like to be able to strip.  dlopen isn't a good 
interface for native loading, since it doesn't guarantee the imports 
are present in the base image.

At this point it's probably worth while talking about what a DXE currently
is.  You take a coff object file, strip the headers and replace the
symbols/relocations with a pre-processed compressed fixup vector..

You could take the code inside DXEGEN and have it all done at runtime
(for a much bigger loader footprint) using a coff format .o file.  If
you wanted to retain symbols for debugging this is probably what you
would need for GDB support.

This is all feasible but a much bigger coding effort than I had planned.