andrewt@watnow.waterloo.edu (Andrew Thomas) (09/14/90)
I am working on an application which uses about 25 DLLs. I have noticed a
couple of very strange things which I was hoping somebody could address:
1) Say I have libraries: A.dll B.dll C.dll where A calls B and B call C.
I make import libraries using implib directly from the DLL, not through
the .def files. All exports in the DLLs use _export keywords.
I link A,B and C without the /CO (codeview debugging info) flag.
Now I decide to debug C. I relink the DLL with /CO, and make a new
import library.
My application now crashes in strange places, or sometimes just
behaves strangely. I have not recompiled any code.
To fix this, I re-link A and B, without recompiling OR changing the
link flags in any way.
Now my program works fine again.
This seems to be a problem specifically to do with the interaction of
the import libraries and the the DLLs such that an import library
becomes inacurate when debugging info is added or removed. A and B
both make use of C's import library when they link.
2) I have some assembler code which makes port IO calls: in and out
assembler instructions. In order for this to work, you must have set
IO privileges on the code segment containing these instructions. This
is done by defining a new segment, and then in the .def file for the
application, using a line like:
SEGMENT MYSEGMENT TYPE 'CODE' IOPL
or some such (I can't remember offhand).
This works just fine if this code is included in a statically linked
library and the SEGMENT line is in the .def file for the application.
Thus I know that the code is correct, and the SEGMENT statement is
correct (I think).
If I put this identical piece of code in a DLL, then put the SEGMENT
statement in the .def file for the DLL, then the code fails presumably
because of a lack of IO privelege. The failure occurs on the first
in or out instruction, with a segmentation fault, just like the
documentation says it should if it has no priveleges. If I put the
SEGMENT line in the application's .def file as well as (or instead of)
in the DLL's .def file, the problem is not solved. This DLL is used
by other DLLs as well as by the application.
Any insights on either problem would be greatly appreciated. The obvious
response to the first question: "just link everything with /CO" is not
practical because of the number of DLLs. It would take codeview forever
to start up.
I can post to newsgroups, but I cannot read them. Any of them. Please
respond to me by email at andrewt@BrockU.ca, or whatever it says on the
from: line at the top of this posting.
Thanks in advance,
Andrew Thomas
--
Andrew Thomas
andrewt@watnow.waterloo.edu Systems Design Eng. University of Waterloo
"If a million people do a stupid thing, it's still a stupid thing." - Opus