Mail Archives: djgpp-workers/2001/12/20/12:02:04
> > 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.
- Raw text -