jan@swivax.UUCP (Jan Wielemaker) (10/27/87)
Some weeks ago I posted a message on unix.questions, but it seems no one there could solve the problem (some wrote me they would like to know as well). here is the PROBLEM: We use a large package of software (executable ca. 1Mb), which consists of an object oriented interface to SunView and a Prolog engine. To extend the object oriented part with very specific classes we dynamically load C object files into the system (using ld -A -T etc.). This works fine, exept for one problem: ADB doesn't make sense out of the core dumps. This is understandable as the symbol table of the original executable isn't complete. Unfortunately adb refuses to use the symbol table of the incremental executable as well (why?). My QUESTIONS: 1) Is there someone there who knows how to get adb producing a stack trace for me? 2) (Even better) Is there someone who has a routine which I can insert as a signal handler, which dumps the stack and exits without producing about 3 Mb of core. Thanks --- Jan Wielemaker (jan@swivax.UUCP, or ...mcvax!swivax!jan) P.s. We are using SUN's under SunUnix 3.2
weiser.pa@Xerox.COM (10/31/87)
If you are running on SunOS (except on sun-4's where this is documented as broken) dbx can debug running processes. Therefore, if your incremental load builds a new map of the combined world, and you then call dbx as follows: dbx new-map-file pid you can look at the incremental world just fine. Of course, later incremental loads must be against the new-map-file, not the original. We are using this trick here, and it works well. The reason you can't look at core dumps this way is that, for core dumps, dbx apparently expects the new-map-file to be a real picture of the entire memory, including the full text and data area. ld -A doesn't produce such a file (the text and data area are only the contents of the most recently loaded thing, even though the symbol table refers to anything ever loaded). -mark
gallmeis@unc.cs.unc.edu (Bill O. Gallmeister) (11/02/87)
In article <442@swivax.UUCP> jan@swivax.UUCP (Jan Wielemaker) writes: >original executable isn't complete. Unfortunately adb refuses to use >the symbol table of the incremental executable as well (why?). I had the (opportunity?) to mess around with this sort of thing over the summer, and I have what may be helpful suggestions. My experience was not with producing composite applications executables, though, and so my knowledge is incomplete. I can try and offer ideas, though. Because they may have some relevance for people out there (Jan mentioned others contacted her (him?) for answers), I post this message to the wizards and to those with questions in the original group. First, adb doesn't recognize multiple symbol tables because it's...adb. If it did neat things for you, it wouldn't be...adb. >My QUESTIONS: > > 1) Is there someone there who knows how to get adb producing a > stack trace for me? The symbols, of course, are the heart of the matter. adb (or whatever) needs to know WHERE everything is in order to print it out. There are two ways to do this: 1. Make adb smarter (requires adb source and a taste for hair-shirt programming). 2. Make sure the program that drops core has a symbol table that reflects reality at the time of the core dump. Assuming you do NOT have adb source, you must make sure that the executable has the "right" symbol table. This is not as hard as you might think. It really relies on how your executables are constructed. The basic executable (call it the kernel) should contain globals and library routines, etcetera, used by the modules you read in dynamically, right? Then, the -A option you use on the modules simply piles the kernel's symbol table into your module, so the module knows where, say, fprintf() is. In essence, the modules contain the kernel's symbol table (modulo any linker-symbol-table cleverness; I don't know what your (or Sun's) linker does). Now, if the kernel symbol table contains the symbols defined in the modules, adb will be able to read those symbols. The desired state of affairs is that the kernel symbol table is the union of ALL the module's symbol tables. What is required is 1. Unique module symbol names (defined externals). Good programming practice has probably already bought you this cookie. 2. A routine, utility or method to catenate symbol tables. Note that it must be smart enough to do away with redundant symbols (I.E. all modules know the symbol fprintf, but you only need one instantiation of same). Look at (2). Conceptually, you must take each module's symbol table and pile it onto the end of the kernel's symbol table. A linker option can do this. You can write a C program. You can even do it with judicious use of size, dd, and a few little glue programs! Given lack of source, though, I suggest the second option. We had source and I chose the second option. > 2) (Even better) Is there someone who has a routine which I can > insert as a signal handler, which dumps the stack and exits > without producing about 3 Mb of core. This is not a terribly hard problem. As a matter of fact, it's a great exercise for those of you who wonder how stack frames are built on the 680x0 (and SPARC!) machines. What you do is write a routine that takes the current stack pointer, finds the frame pointer in the current activation record, prints the frame, follows the frame pointer down to the next activation record, etc., until no AR's are left to be dumped. Of cource, you have to code it in assembler. > Thanks --- Jan Wielemaker (jan@swivax.UUCP, or ...mcvax!swivax!jan) I hope this DID help you. Anyone else with comments here, please let us all know about them -- I'm interested in this area, as well. For instance, has anyone with the adb source gotten around to hacking in incrementally-loaded executable debugging into it? We were planning on it, but it hadn't happened by the time I went to school. Who knows -- it'll no doubt be there for me when I go back at Christmas. Mmm, a little BourneGol on a cold winter's night...someone pass me the Schnapps... -- Bill O. Gallmeister unc!gallmeis "You're just one of those boys with a sink full of dishes. You ain't looking for nothing but someone dumb enough to come and wash your dishes. You go home and play your radio."