4187119d |
1 | This is GDB, the GNU source-level debugger, presently running under un*x. |
3bf57d21 |
2 | |
4187119d |
3 | Before compiling GDB, you must tell GDB what kind of machine you are |
4 | running on. To do this, type `config.gdb machine', where machine is |
5 | something like `vax' or `sun2'. For a list of valid machine types, |
6 | type `config.gdb'. |
7 | |
8 | Normally config.gdb edits the makefile as necessary. If you have to |
9 | edit the makefile on a standard machine listed in config.gdb this |
10 | should be considered a bug and reported as such. |
3bf57d21 |
11 | |
12 | Once these files are set up, just `make' will do everything, |
13 | producing an executable `gdb' in this directory. |
14 | |
4187119d |
15 | If you want a new (current to this release) version of the manual, you |
16 | will have to use the gdb.texinfo file provided with this distribution. |
17 | The gdb.texinfo file requires the texinfo-format-buffer command from |
18 | emacs 18.55 or later. |
19 | |
20 | About languages other than C... |
21 | |
1c997a4a |
22 | C++ support has been integrated into gdb. GDB should work with |
23 | FORTRAN programs (if you have problem, please send a bug report), but |
24 | I am not aware of anyone who is working on getting it to use the |
25 | syntax of any language other than C or C++. Pascal programs which use |
26 | sets, subranges, file variables, or nested functions will not |
27 | currently work. |
4187119d |
28 | |
29 | About -gg format... |
30 | |
31 | Currently GDB version 3.x does *not* support GCC's -gg format. This |
1c997a4a |
32 | is because it (in theory) has fast enough startup on dbx debugging |
4187119d |
33 | format object files that -gg format is unnecessary (and hence |
34 | undesirable, since it wastes space and processing power in gcc). I |
35 | would like to hear people's opinions on the amount of time currently |
36 | spent in startup; is it fast enough? |
37 | |
38 | About remote debugging... |
39 | |
40 | The two files remote-multi.shar and remote-sa.m68k.shar contain two |
41 | examples of a remote stub to be used with remote.c. The the -multi |
42 | file is a general stub that can probably be running on various |
43 | different flavors of unix to allow debugging over a serial line from |
44 | one machine to another. The remote-sa.m68k.shar is designed to run |
45 | standalone on a 68k type cpu and communicate properley with the |
46 | remote.c stub over a serial line. |
47 | |
48 | About reporting bugs... |
49 | |
50 | The correct address for reporting bugs found with gdb is |
51 | "bug-gdb@prep.ai.mit.edu". Please send all bugs to that address. |
52 | |
53 | About xgdb... |
54 | |
55 | xgdb.c was provided to us by the user community; it is not an integral |
56 | part of the gdb distribution. The problem of providing visual |
57 | debugging support on top of gdb is peripheral to the GNU project and |
58 | (at least right now) we can't afford to put time into it. So while we |
59 | will be happy to incorporate user fixes to xgdb.c, we do not guarantee |
60 | that it will work and we will not fix bugs reported in it. Someone is |
61 | working on writing a new XGDB, so improving (e.g. by fixing it so that |
62 | it will work, if it doesn't currently) the current one is not worth it. |
63 | |
64 | For those intersted in auto display of source and the availability of |
65 | an editor while debugging I suggest trying gdb-mode in gnu-emacs. |
66 | Comments on this mode are welcome. |
3bf57d21 |
67 | |
4187119d |
68 | About the machine-dependent files... |
3bf57d21 |
69 | |
4187119d |
70 | m-<machine>.h (param.h is a link to this file). |
3bf57d21 |
71 | This file contains macro definitions that express information |
72 | about the machine's registers, stack frame format and instructions. |
73 | |
4187119d |
74 | <machine>-opcode.h (opcode.h is a link to this file). |
75 | <machine>-pinsn.c (pinsn.c is a link to this file). |
3bf57d21 |
76 | These files contain the information necessary to print instructions |
77 | for your cpu type. |
e91b87a3 |
78 | |
4187119d |
79 | <machine>-dep.c (dep.c is a link to this file). |
e91b87a3 |
80 | Those routines which provide a low level interface to ptrace and which |
81 | tend to be machine-dependent. (The machine-independent routines are in |
82 | `infrun.c' and `inflow.c') |
83 | |
4187119d |
84 | About writing code for GDB... |
85 | |
86 | We appreciate having users contribute code that is of general use, but |
87 | for it to be included in future GDB releases it must be cleanly |
88 | written. We do not want to include changes that will needlessly make future |
89 | maintainance difficult. It is not much harder to do things right, and |
90 | in the long term it is worth it to the GNU project, and probably to |
91 | you individually as well. |
92 | |
93 | Please code according to the GNU coding standards. If you do not have |
94 | a copy, you can request one by sending mail to gnu@prep.ai.mit.edu. |
95 | |
96 | Please try to avoid making machine-specific changes to |
97 | machine-independent files (i.e. all files except "param.h" and |
98 | "dep.c". "pinsn.c" and "opcode.h" are processor-specific but not |
99 | operating system-dependent). If this is unavoidable, put a hook in |
100 | the machine-independent file which calls a (possibly) |
101 | machine-dependent macro (for example, the IGNORE_SYMBOL macro can be |
102 | used for any symbols which need to be ignored on a specific machine. |
1c997a4a |
103 | Calling IGNORE_SYMBOL in dbxread.c is a lot cleaner than a maze of #if |
104 | defined's). The machine-independent code should do whatever "most" |
105 | machines want if the macro is not defined in param.h. Using #if |
106 | defined can sometimes be OK (e.g. SET_STACK_LIMIT_HUGE) but should be |
4187119d |
107 | conditionalized on a specific feature of an operating system (set in |
1c997a4a |
108 | param.h) rather than something like #if defined(vax) or #if |
109 | defined(SYSV). |
4187119d |
110 | |
111 | It is better to replace entire routines which may be system-specific, |
112 | rather than put in a whole bunch of hooks which are probably not going |
113 | to be helpful for any purpose other than your changes. For example, |
114 | if you want to modify dbxread.c to deal with DBX debugging symbols |
1c997a4a |
115 | which are in COFF files rather than BSD a.out files, do something |
4187119d |
116 | along the lines of a macro GET_NEXT_SYMBOL, which could have |
117 | different definitions for COFF and a.out, rather than trying to put |
118 | the necessary changes throughout all the code in dbxread.c that |
1c997a4a |
119 | currently assumes BSD format. |
4187119d |
120 | |
121 | Please avoid duplicating code. For example, if something needs to be |
122 | changed in read_inferior_memory, it is very painful because there is a |
1c997a4a |
123 | copy in every dep.c file. The correct way to do this is to put (in |
124 | this case) the standard ptrace interfaces in a separate file ptrace.c, |
125 | which is used by all systems which have ptrace. ptrace.c would deal |
126 | with variations between systems the same way any system-independent |
127 | file would (hooks, #if defined, etc.). |
4187119d |
128 | |
e91b87a3 |
129 | About debugging gdb with itself... |
130 | |
131 | You probably want to do a "make TAGS" after you configure your |
132 | distribution; this will put the machine dependent routines for your |
133 | local machine where they will be accessed first by a M-period . |
134 | |
1c997a4a |
135 | Also, make sure that you've compiled gdb with your local cc or taken |
136 | appropriate precautions regarding ansification of include files. See |
137 | the Makefile for more information. |
e91b87a3 |
138 | |
139 | The "info" command, when executed without a subcommand in a gdb being |
140 | debugged by gdb, will pop you back up to the top level gdb. See |
141 | .gdbinit for more details. |
142 | |