brian@nancy.UUCP (Brian Kilgore WILCO) (08/05/89)
I am trying to get Gdb 3.1.2 to compile on an AT&T UNIX PC (7300, 3B1). I have
made the proper changes to files to get Gdb to compile, but I need to find out
the values to the following defines:
FUNCTION_START_OFFSET
KERNEL_U_ADDR
STACK_END_ADDR
I have tried to look up these values but have been unable to find them so far.
If someone has these values or files containing these values or a newer version
of Gdb that will compile on the UNIX PC could they please mail them to me
(because I do not have access to ftp or uucp from the file servers). If and
when I get working I will post how (if needed) to get it working.
Thanks.
Brian Kilgoretkacik@rphroy.UUCP (Tom Tkacik) (08/15/89)
Brian Kilgore writes: > I am trying to get Gdb 3.1.2 to compile on an AT&T UNIX PC (7300, 3B1). I have >made the proper changes to files to get Gdb to compile, but I need to find out >the values to the following defines: > FUNCTION_START_OFFSET > KERNEL_U_ADDR > STACK_END_ADDR >I have tried to look up these values but have been unable to find them so far. I have been trying to get gdb3.0 working on the unixpc, with marginal success. Most things appear to be working, except that gdb seems to be able to find the source to only the last file linked into the executable. If the program only has one source file, then all is well, but then that's not very useful :-). These are the values that I am using. I got them in a set of patches posted by (I believe) Bob Rose (rrr@naucse.UUCP), for gdb2.5. I can mail them if needed. They are a great place to start from. I do not know where he got these numbers, but they seem to work. #define FUNCTION_START_OFFSET 0 #define KERNEL_U_ADDR 04266 /* my mom told me so! */ #define STACK_END_ADDR 0x1000000 Good luck, and let the world know if you get things working. I would be very interested in hearing if you figure out how to get gdb to understand multiple source files again. Gdb2.5 did not have this problem, but it did not try to incrementally read in the symbol table. I think that is the cause. --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette -- --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik "If you can't stand the bugs, stay out of the roach-motel." Ron Guilmette
mike@thor.acc.stolaf.edu (Mike Haertel) (08/19/89)
In article <15334@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: >Brian Kilgore writes: >> I am trying to get Gdb 3.1.2 to compile on an AT&T UNIX PC (7300, 3B1). I have >>made the proper changes to files to get Gdb to compile, but I need to find out >>the values to the following defines: >> FUNCTION_START_OFFSET >> KERNEL_U_ADDR >> STACK_END_ADDR >>I have tried to look up these values but have been unable to find them so far. > > [ . . . ] > > These are the values that I am using. I got them in a set of patches >posted by (I believe) Bob Rose (rrr@naucse.UUCP), for gdb2.5. >I can mail them if needed. They are a great place to start from. >I do not know where he got these numbers, but they seem to work. > >#define FUNCTION_START_OFFSET 0 >#define KERNEL_U_ADDR 04266 /* my mom told me so! */ >#define STACK_END_ADDR 0x1000000 I made gdb 3.1.something work on my 3b1. But I could never get the coffread.c stuff to work properly, so I finally switched to BSD format symbol tables (using the GNU assembler and linker, and a variation on the robotussin theme). Unfortunately, due to disk problems I have lost the source code. I was planning on completely redoing it with gdb 3.2 anyway, so I'm not too unhappy. Last I heard, the incremental symbol-table loading was only implemented in dbxread.c, so there is another good reason to prefer BSD symbol tables. FUNCTION_START_OFFSET is certainly 0 on any 68000 machine. The stack builds downward from 0x300000, so that is STACK_END_ADDR. This is easily deduced from /usr/include/sys/something-or-other.h. The u BLOCK in the kernel is located at 0x70000 (see the include files), and the u STRUCTURE bizarrely begins 0x900 bytes further in. I used 0x70000 for KERNEL_U_ADDR, together with a kludge to offset references to the u structure another 0x900 bytes. If it weren't for the problem of reading core files, which begin with a copy of the u block, I would just have defined KERNEL_U_ADDR to 0x70900. The breakpoint instructions are slightly different; you can deduce them with adb. (Set a breakpoint at the beginning of a function, then call another function to print it out as an array of words.) Both times I ported it (2.something and 3.1.something) I started with the sun 2 configuration file and edited it until it worked. -- Mike Haertel <mike@stolaf.edu> ``There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.'' -- J. S. Bach