jan@swivax.UUCP (Jan Wielemaker) (10/13/87)
We've got a system called PCE-Prolog, consisting of an object oriented interface/data management system, connected to Prolog. We can dynamically add new classes to the object oriented part by writing C-code, compiling this into object files and then load these into the running PCE process. This is done by calling 'ld' to create an incremental executable with some base address, loading the executable and resolving the entry points. This feature is mainly used for prototyping classes. Problem is that on an error 'adb' doesn't understand the core file as the symbol table is incomplete. The symbol table of the created executable is complete, but as the text of this file is incomplete adb still refuses to produce a stack trace. (The system is running on SUN, under SunUnix 3.2). My questions are: 1) Does anyone know a way to have 'adb' produce a stack trace for me? 2) (Even better) does anyone have a routine, which I can insert as signal handler, which prints the stack for me, given some symbol table. Thanks --- Jan
daveb@geac.UUCP (10/17/87)
In article <427@swivax.UUCP> jan@swivax.UUCP (Jan Wielemaker) writes: >...dynamically add new classes to the object oriented part by writing >C-code, compiling this into object files and then load these into the >running PCE process. This is done by calling 'ld' to create an >incremental executable with some base address, loading the executable >and resolving the entry points. This feature is mainly used for >prototyping classes. > >Problem is that on an error 'adb' doesn't understand the core file as >the symbol table is incomplete. The symbol table of the created >executable is complete, but as the text of this file is incomplete adb >still refuses to produce a stack trace. (The system is running on SUN, >under SunUnix 3.2). I (and, I suspect, several other people) would be happy to munge around in incremental loaded-programs if we could get incremental loading to work properly.... If memory serves, someone asked for experiences with ld in creating incremental loadables about a week ago. Would you be so kind as to write us a paragraph or two on using the incremental loading feature, and include an example? I suspect if others could get started, they might help with some of the adb/dbx problems. --dave (GCOS is alive, well and living on the Riviera) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
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."