Gdb on a Unix PC (7300, 3b1)

[Mike Haertel]

In article <15334 at rphroy.UUCP> tkacik at 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 at 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 at 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