Board index » cppbuilder » Need help debugging a DLL

2005-01-17 07:32:59 AM
cppbuilder71
Hi all,
I'm having some big problems trying to debug a dll I've written under
TD32. I've tried the steps found here having doing some searching:
www.xploiter.com/programming/c/borland/3175.html
But I am still unable to get the debug symbols to load for my dll. It
just keeps giving me dll is not loaded. I've even tried to load the
symbols just before and right after executing a function that resides in
the dll from my test program and it still gives me that same error msg.
I'm doing this from the Module option found under view or by pressing F3.
Any idea what I'm doing wrong or forgetting? How can I get this de{*word*81}
to debug my dll?
Thanks
 

The first possiblity is that the dll shares a base filename with a dll that
is already loaded. If so then Windows' lookup scheme in finding the dll may
be finding and loading the wrong one so change the dll name and rebuild the
dll and the program. Assuming that you are using Win95/98 or have user
writes set to administrator, this program should show the dll's that are
loaded in its module list area
www.mulroy.org/plist.exe
Another possiblity is that the dll does not have debug info. If you run
tdump.exe on the dll's *.tds file to see if it has debug records. Because
there is a lot of output it is usually better to watch a screen at a time
with a command like this
tdump dllname.tds | more
If none of the above help then try starting with a simple example and
working up from there.
In the group
borland.public.attachments
I have posted a message with a subject of
TESTDLL.ZIP is attached
Read that message and get the attachment. It has two small source files,
main.cpp and testdll.cpp. The make file is implicit.mak
Unzip the dll into a new directory, make that directory the default.
Then create the executable and dll with this command
make -f implicit.mak
(the space after the -f and the extension .mak are optional)
Now give this command
td32 main.exe
Step through with the F7 key. You will see that you can step into the dll
and view its source code without any need to do View|Module or load the
symbol table. You only need to do those things when circumstances get
difficult.
Side note: what is in testdll.zip is a subset of what is in the following
zip file
www.mulroy.org/hello.zip
It contains a set of demo programs, each being cut down to where it
illustrates a simple point, console and gui programs, implicit and explicit
linked dll's, use of Windows' file selection common dialog and some other
things. If you get it then unzip to a new directory with creating
directories enabled as it unzips to many example directories.
The file is set up for C++ Builder but I think you'll be able to muddle
through with it if using Borland C++.
. Ed

Thanks for the suggestions and quick response. Your demo attachment has
helped me narrow down where the source of the problem was coming from.
After examining how your demo was compiled and comparing it to mine, I
have come to conclude that manually invoking the linker causes this
strange quirk to show up.
I wrote an auto makefile generator a while back. When I work with a
project I have the makefiles automatically generated from that and
customize the settings in there as needed. But I have the rules setup in
such a way that sources that need to be compiled invoke bcc32 like usual
except it doesn't do the linking phrase. This is repeated for each and
every source that needs to be compiled in my project. Then finally the
rule with the ilink32 is invoked to link everything together to produce
the final exe, dll, static lib or whatever.
This setup seems to work fine so far up until now. The only thing I can't
figure out is what is bcc doing when it invokes ilink that isn't being
done when I invoke it manually? I made a dummy ilink32.exe that captures
and prints out the responsefile that's past to it from bcc. I duplicated
the options and switches exactly but the same problem still persist. So
I'm kind of stump on that.
I guess for the time being I'll have to modify the linking rule to
execute bcc32 and have it invoke ilink indirectly instead. If you have
any idea as to what the problem might be or if there's something I'm
overlooking please let me know.
Thanks for your help
 

{smallsort}

I have tried this in various configurations using both of
Borland C++ (BC5) and C++ Builder (BCB).
The BCB version was built in two configurations, built
allowing the compiler to call the linker and built by
explicitly calling the linker.
The BC5 version was also built as above but BC5 has two
linkers, ilink32.exe, the incremental linker of the same
name as the linker in BCB and which was new in BC5 and
tlink32.exe, the then current version of the traditional 32
bit linker used in the Borland C++ series of compilers from
the time 32 bit support was added.
Only when built with BC5 by allowing the compiler to call
the linker or by explicitly calling the linker myself but
using tlink32.exe was a set of executable and dll created
for which td32.exe would step into the dll source code
without manual intervention to load the dll's symbol table.
Because you could step into the dll when the compiler was
allowed to call the linker my conclusion is that you are
using Borland C++ and not C++ Builder. Your complaint that
you cannot step in without manual intervention if you called
the linker directly will most likely be solved by calling
tlink32.exe instead of ilink32.exe
The make files used to build these tests are in a zip file
attached to a message with the subject "various makefiles"
and posted into the group
borland.public.attachments
If you use those make files you must alter some paths. In
the make files I have defined macros which specify the paths
to the various C++ Builder and Borland C++ items on my
machine. Those tools are not likely to be located in those
same paths on your machine so the macros will need to be
altered.
. Ed