OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [insight/] [gdb/] [doc/] [gdbint.info-4] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 578 markom
This is gdbint.info, produced by makeinfo version 4.0 from
2
./gdbint.texinfo.
3
 
4
INFO-DIR-SECTION Programming & development tools.
5
START-INFO-DIR-ENTRY
6
START-INFO-DIR-ENTRY
7
* Gdb-Internals: (gdbint).      The GNU debugger's internals.
8
END-INFO-DIR-ENTRY
9
END-INFO-DIR-ENTRY
10
 
11
   This file documents the internals of the GNU debugger GDB.
12
Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001    Free
13
Software Foundation, Inc.  Contributed by Cygnus Solutions.  Written by
14
John Gilmore.  Second Edition by Stan Shebs.
15
 
16
   Permission is granted to copy, distribute and/or modify this document
17
under the terms of the GNU Free Documentation License, Version 1.1 or
18
any later version published by the Free Software Foundation; with the
19
Invariant Sections being "Algorithms" and "Porting GDB", with the
20
Front-Cover texts being "A GNU Manual," and with the Back-Cover Texts
21
as in (a) below.
22
 
23
   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
24
modify this GNU Manual, like GNU software.  Copies published by the Free
25
Software Foundation raise funds for GNU development."
26
 
27

28
File: gdbint.info,  Node: Target Vector Definition,  Next: Native Debugging,  Prev: Target Architecture Definition,  Up: Top
29
 
30
Target Vector Definition
31
************************
32
 
33
   The target vector defines the interface between GDB's abstract
34
handling of target systems, and the nitty-gritty code that actually
35
exercises control over a process or a serial port.  GDB includes some
36
30-40 different target vectors; however, each configuration of GDB
37
includes only a few of them.
38
 
39
File Targets
40
============
41
 
42
   Both executables and core files have target vectors.
43
 
44
Standard Protocol and Remote Stubs
45
==================================
46
 
47
   GDB's file `remote.c' talks a serial protocol to code that runs in
48
the target system.  GDB provides several sample "stubs" that can be
49
integrated into target programs or operating systems for this purpose;
50
they are named `*-stub.c'.
51
 
52
   The GDB user's manual describes how to put such a stub into your
53
target code.  What follows is a discussion of integrating the SPARC
54
stub into a complicated operating system (rather than a simple
55
program), by Stu Grossman, the author of this stub.
56
 
57
   The trap handling code in the stub assumes the following upon entry
58
to `trap_low':
59
 
60
  1. %l1 and %l2 contain pc and npc respectively at the time of the
61
     trap;
62
 
63
  2. traps are disabled;
64
 
65
  3. you are in the correct trap window.
66
 
67
   As long as your trap handler can guarantee those conditions, then
68
there is no reason why you shouldn't be able to "share" traps with the
69
stub.  The stub has no requirement that it be jumped to directly from
70
the hardware trap vector.  That is why it calls `exceptionHandler()',
71
which is provided by the external environment.  For instance, this could
72
set up the hardware traps to actually execute code which calls the stub
73
first, and then transfers to its own trap handler.
74
 
75
   For the most point, there probably won't be much of an issue with
76
"sharing" traps, as the traps we use are usually not used by the kernel,
77
and often indicate unrecoverable error conditions.  Anyway, this is all
78
controlled by a table, and is trivial to modify.  The most important
79
trap for us is for `ta 1'.  Without that, we can't single step or do
80
breakpoints.  Everything else is unnecessary for the proper operation
81
of the debugger/stub.
82
 
83
   From reading the stub, it's probably not obvious how breakpoints
84
work.  They are simply done by deposit/examine operations from GDB.
85
 
86
ROM Monitor Interface
87
=====================
88
 
89
Custom Protocols
90
================
91
 
92
Transport Layer
93
===============
94
 
95
Builtin Simulator
96
=================
97
 
98

99
File: gdbint.info,  Node: Native Debugging,  Next: Support Libraries,  Prev: Target Vector Definition,  Up: Top
100
 
101
Native Debugging
102
****************
103
 
104
   Several files control GDB's configuration for native support:
105
 
106
`gdb/config/ARCH/XYZ.mh'
107
     Specifies Makefile fragments needed when hosting _or native_ on
108
     machine XYZ.  In particular, this lists the required
109
     native-dependent object files, by defining `NATDEPFILES=...'.
110
     Also specifies the header file which describes native support on
111
     XYZ, by defining `NAT_FILE= nm-XYZ.h'.  You can also define
112
     `NAT_CFLAGS', `NAT_ADD_FILES', `NAT_CLIBS', `NAT_CDEPS', etc.; see
113
     `Makefile.in'.
114
 
115
`gdb/config/ARCH/nm-XYZ.h'
116
     (`nm.h' is a link to this file, created by `configure').  Contains
117
     C macro definitions describing the native system environment, such
118
     as child process control and core file support.
119
 
120
`gdb/XYZ-nat.c'
121
     Contains any miscellaneous C code required for this native support
122
     of this machine.  On some machines it doesn't exist at all.
123
 
124
   There are some "generic" versions of routines that can be used by
125
various systems.  These can be customized in various ways by macros
126
defined in your `nm-XYZ.h' file.  If these routines work for the XYZ
127
host, you can just include the generic file's name (with `.o', not
128
`.c') in `NATDEPFILES'.
129
 
130
   Otherwise, if your machine needs custom support routines, you will
131
need to write routines that perform the same functions as the generic
132
file.  Put them into `XYZ-nat.c', and put `XYZ-nat.o' into
133
`NATDEPFILES'.
134
 
135
`inftarg.c'
136
     This contains the _target_ops vector_ that supports Unix child
137
     processes on systems which use ptrace and wait to control the
138
     child.
139
 
140
`procfs.c'
141
     This contains the _target_ops vector_ that supports Unix child
142
     processes on systems which use /proc to control the child.
143
 
144
`fork-child.c'
145
     This does the low-level grunge that uses Unix system calls to do a
146
     "fork and exec" to start up a child process.
147
 
148
`infptrace.c'
149
     This is the low level interface to inferior processes for systems
150
     using the Unix `ptrace' call in a vanilla way.
151
 
152
Native core file Support
153
========================
154
 
155
`core-aout.c::fetch_core_registers()'
156
     Support for reading registers out of a core file.  This routine
157
     calls `register_addr()', see below.  Now that BFD is used to read
158
     core files, virtually all machines should use `core-aout.c', and
159
     should just provide `fetch_core_registers' in `XYZ-nat.c' (or
160
     `REGISTER_U_ADDR' in `nm-XYZ.h').
161
 
162
`core-aout.c::register_addr()'
163
     If your `nm-XYZ.h' file defines the macro `REGISTER_U_ADDR(addr,
164
     blockend, regno)', it should be defined to set `addr' to the
165
     offset within the `user' struct of GDB register number `regno'.
166
     `blockend' is the offset within the "upage" of `u.u_ar0'.  If
167
     `REGISTER_U_ADDR' is defined, `core-aout.c' will define the
168
     `register_addr()' function and use the macro in it.  If you do not
169
     define `REGISTER_U_ADDR', but you are using the standard
170
     `fetch_core_registers()', you will need to define your own version
171
     of `register_addr()', put it into your `XYZ-nat.c' file, and be
172
     sure `XYZ-nat.o' is in the `NATDEPFILES' list.  If you have your
173
     own `fetch_core_registers()', you may not need a separate
174
     `register_addr()'.  Many custom `fetch_core_registers()'
175
     implementations simply locate the registers themselves.
176
 
177
   When making GDB run native on a new operating system, to make it
178
possible to debug core files, you will need to either write specific
179
code for parsing your OS's core files, or customize `bfd/trad-core.c'.
180
First, use whatever `#include' files your machine uses to define the
181
struct of registers that is accessible (possibly in the u-area) in a
182
core file (rather than `machine/reg.h'), and an include file that
183
defines whatever header exists on a core file (e.g. the u-area or a
184
`struct core').  Then modify `trad_unix_core_file_p' to use these
185
values to set up the section information for the data segment, stack
186
segment, any other segments in the core file (perhaps shared library
187
contents or control information), "registers" segment, and if there are
188
two discontiguous sets of registers (e.g.  integer and float), the
189
"reg2" segment.  This section information basically delimits areas in
190
the core file in a standard way, which the section-reading routines in
191
BFD know how to seek around in.
192
 
193
   Then back in GDB, you need a matching routine called
194
`fetch_core_registers'.  If you can use the generic one, it's in
195
`core-aout.c'; if not, it's in your `XYZ-nat.c' file.  It will be
196
passed a char pointer to the entire "registers" segment, its length,
197
and a zero; or a char pointer to the entire "regs2" segment, its
198
length, and a 2.  The routine should suck out the supplied register
199
values and install them into GDB's "registers" array.
200
 
201
   If your system uses `/proc' to control processes, and uses ELF
202
format core files, then you may be able to use the same routines for
203
reading the registers out of processes and out of core files.
204
 
205
ptrace
206
======
207
 
208
/proc
209
=====
210
 
211
win32
212
=====
213
 
214
shared libraries
215
================
216
 
217
Native Conditionals
218
===================
219
 
220
   When GDB is configured and compiled, various macros are defined or
221
left undefined, to control compilation when the host and target systems
222
are the same.  These macros should be defined (or left undefined) in
223
`nm-SYSTEM.h'.
224
 
225
`ATTACH_DETACH'
226
     If defined, then GDB will include support for the `attach' and
227
     `detach' commands.
228
 
229
`CHILD_PREPARE_TO_STORE'
230
     If the machine stores all registers at once in the child process,
231
     then define this to ensure that all values are correct.  This
232
     usually entails a read from the child.
233
 
234
     [Note that this is incorrectly defined in `xm-SYSTEM.h' files
235
     currently.]
236
 
237
`FETCH_INFERIOR_REGISTERS'
238
     Define this if the native-dependent code will provide its own
239
     routines `fetch_inferior_registers' and `store_inferior_registers'
240
     in `HOST-nat.c'.  If this symbol is _not_ defined, and
241
     `infptrace.c' is included in this configuration, the default
242
     routines in `infptrace.c' are used for these functions.
243
 
244
`FILES_INFO_HOOK'
245
     (Only defined for Convex.)
246
 
247
`FP0_REGNUM'
248
     This macro is normally defined to be the number of the first
249
     floating point register, if the machine has such registers.  As
250
     such, it would appear only in target-specific code.  However,
251
     `/proc' support uses this to decide whether floats are in use on
252
     this target.
253
 
254
`GET_LONGJMP_TARGET'
255
     For most machines, this is a target-dependent parameter.  On the
256
     DECstation and the Iris, this is a native-dependent parameter,
257
     since `setjmp.h' is needed to define it.
258
 
259
     This macro determines the target PC address that `longjmp' will
260
     jump to, assuming that we have just stopped at a longjmp
261
     breakpoint.  It takes a `CORE_ADDR *' as argument, and stores the
262
     target PC value through this pointer.  It examines the current
263
     state of the machine as needed.
264
 
265
`I386_USE_GENERIC_WATCHPOINTS'
266
     An x86-based machine can define this to use the generic x86
267
     watchpoint support; see *Note I386_USE_GENERIC_WATCHPOINTS:
268
     Algorithms.
269
 
270
`KERNEL_U_ADDR'
271
     Define this to the address of the `u' structure (the "user
272
     struct", also known as the "u-page") in kernel virtual memory.
273
     GDB needs to know this so that it can subtract this address from
274
     absolute addresses in the upage, that are obtained via ptrace or
275
     from core files.  On systems that don't need this value, set it to
276
     zero.
277
 
278
`KERNEL_U_ADDR_BSD'
279
     Define this to cause GDB to determine the address of `u' at
280
     runtime, by using Berkeley-style `nlist' on the kernel's image in
281
     the root directory.
282
 
283
`KERNEL_U_ADDR_HPUX'
284
     Define this to cause GDB to determine the address of `u' at
285
     runtime, by using HP-style `nlist' on the kernel's image in the
286
     root directory.
287
 
288
`ONE_PROCESS_WRITETEXT'
289
     Define this to be able to, when a breakpoint insertion fails, warn
290
     the user that another process may be running with the same
291
     executable.
292
 
293
`PREPARE_TO_PROCEED (SELECT_IT)'
294
     This (ugly) macro allows a native configuration to customize the
295
     way the `proceed' function in `infrun.c' deals with switching
296
     between threads.
297
 
298
     In a multi-threaded task we may select another thread and then
299
     continue or step.  But if the old thread was stopped at a
300
     breakpoint, it will immediately cause another breakpoint stop
301
     without any execution (i.e. it will report a breakpoint hit
302
     incorrectly).  So GDB must step over it first.
303
 
304
     If defined, `PREPARE_TO_PROCEED' should check the current thread
305
     against the thread that reported the most recent event.  If a
306
     step-over is required, it returns TRUE.  If SELECT_IT is non-zero,
307
     it should reselect the old thread.
308
 
309
`PROC_NAME_FMT'
310
     Defines the format for the name of a `/proc' device.  Should be
311
     defined in `nm.h' _only_ in order to override the default
312
     definition in `procfs.c'.
313
 
314
`PTRACE_FP_BUG'
315
     See `mach386-xdep.c'.
316
 
317
`PTRACE_ARG3_TYPE'
318
     The type of the third argument to the `ptrace' system call, if it
319
     exists and is different from `int'.
320
 
321
`REGISTER_U_ADDR'
322
     Defines the offset of the registers in the "u area".
323
 
324
`SHELL_COMMAND_CONCAT'
325
     If defined, is a string to prefix on the shell command used to
326
     start the inferior.
327
 
328
`SHELL_FILE'
329
     If defined, this is the name of the shell to use to run the
330
     inferior.  Defaults to `"/bin/sh"'.
331
 
332
`SOLIB_ADD (FILENAME, FROM_TTY, TARG)'
333
     Define this to expand into an expression that will cause the
334
     symbols in FILENAME to be added to GDB's symbol table.
335
 
336
`SOLIB_CREATE_INFERIOR_HOOK'
337
     Define this to expand into any shared-library-relocation code that
338
     you want to be run just after the child process has been forked.
339
 
340
`START_INFERIOR_TRAPS_EXPECTED'
341
     When starting an inferior, GDB normally expects to trap twice;
342
     once when the shell execs, and once when the program itself execs.
343
     If the actual number of traps is something other than 2, then
344
     define this macro to expand into the number expected.
345
 
346
`SVR4_SHARED_LIBS'
347
     Define this to indicate that SVR4-style shared libraries are in
348
     use.
349
 
350
`USE_PROC_FS'
351
     This determines whether small routines in `*-tdep.c', which
352
     translate register values between GDB's internal representation
353
     and the `/proc' representation, are compiled.
354
 
355
`U_REGS_OFFSET'
356
     This is the offset of the registers in the upage.  It need only be
357
     defined if the generic ptrace register access routines in
358
     `infptrace.c' are being used (that is, `infptrace.c' is configured
359
     in, and `FETCH_INFERIOR_REGISTERS' is not defined).  If the
360
     default value from `infptrace.c' is good enough, leave it
361
     undefined.
362
 
363
     The default value means that u.u_ar0 _points to_ the location of
364
     the registers.  I'm guessing that `#define U_REGS_OFFSET 0' means
365
     that `u.u_ar0' _is_ the location of the registers.
366
 
367
`CLEAR_SOLIB'
368
     See `objfiles.c'.
369
 
370
`DEBUG_PTRACE'
371
     Define this to debug `ptrace' calls.
372
 
373

374
File: gdbint.info,  Node: Support Libraries,  Next: Coding,  Prev: Native Debugging,  Up: Top
375
 
376
Support Libraries
377
*****************
378
 
379
BFD
380
===
381
 
382
   BFD provides support for GDB in several ways:
383
 
384
_identifying executable and core files_
385
     BFD will identify a variety of file types, including a.out, coff,
386
     and several variants thereof, as well as several kinds of core
387
     files.
388
 
389
_access to sections of files_
390
     BFD parses the file headers to determine the names, virtual
391
     addresses, sizes, and file locations of all the various named
392
     sections in files (such as the text section or the data section).
393
     GDB simply calls BFD to read or write section X at byte offset Y
394
     for length Z.
395
 
396
_specialized core file support_
397
     BFD provides routines to determine the failing command name stored
398
     in a core file, the signal with which the program failed, and
399
     whether a core file matches (i.e. could be a core dump of) a
400
     particular executable file.
401
 
402
_locating the symbol information_
403
     GDB uses an internal interface of BFD to determine where to find
404
     the symbol information in an executable file or symbol-file.  GDB
405
     itself handles the reading of symbols, since BFD does not
406
     "understand" debug symbols, but GDB uses BFD's cached information
407
     to find the symbols, string table, etc.
408
 
409
opcodes
410
=======
411
 
412
   The opcodes library provides GDB's disassembler.  (It's a separate
413
library because it's also used in binutils, for `objdump').
414
 
415
readline
416
========
417
 
418
mmalloc
419
=======
420
 
421
libiberty
422
=========
423
 
424
gnu-regex
425
=========
426
 
427
   Regex conditionals.
428
 
429
`C_ALLOCA'
430
 
431
`NFAILURES'
432
 
433
`RE_NREGS'
434
 
435
`SIGN_EXTEND_CHAR'
436
 
437
`SWITCH_ENUM_BUG'
438
 
439
`SYNTAX_TABLE'
440
 
441
`Sword'
442
 
443
`sparc'
444
include
445
=======
446
 
447

448
File: gdbint.info,  Node: Coding,  Next: Porting GDB,  Prev: Support Libraries,  Up: Top
449
 
450
Coding
451
******
452
 
453
   This chapter covers topics that are lower-level than the major
454
algorithms of GDB.
455
 
456
Cleanups
457
========
458
 
459
   Cleanups are a structured way to deal with things that need to be
460
done later.  When your code does something (like `malloc' some memory,
461
or open a file) that needs to be undone later (e.g., free the memory or
462
close the file), it can make a cleanup.  The cleanup will be done at
463
some future point: when the command is finished, when an error occurs,
464
or when your code decides it's time to do cleanups.
465
 
466
   You can also discard cleanups, that is, throw them away without doing
467
what they say.  This is only done if you ask that it be done.
468
 
469
   Syntax:
470
 
471
`struct cleanup *OLD_CHAIN;'
472
     Declare a variable which will hold a cleanup chain handle.
473
 
474
`OLD_CHAIN = make_cleanup (FUNCTION, ARG);'
475
     Make a cleanup which will cause FUNCTION to be called with ARG (a
476
     `char *') later.  The result, OLD_CHAIN, is a handle that can be
477
     passed to `do_cleanups' or `discard_cleanups' later.  Unless you
478
     are going to call `do_cleanups' or `discard_cleanups' yourself,
479
     you can ignore the result from `make_cleanup'.
480
 
481
`do_cleanups (OLD_CHAIN);'
482
     Perform all cleanups done since `make_cleanup' returned OLD_CHAIN.
483
     E.g.:
484
 
485
          make_cleanup (a, 0);
486
          old = make_cleanup (b, 0);
487
          do_cleanups (old);
488
 
489
     will call `b()' but will not call `a()'.  The cleanup that calls
490
     `a()' will remain in the cleanup chain, and will be done later
491
     unless otherwise discarded.
492
 
493
`discard_cleanups (OLD_CHAIN);'
494
     Same as `do_cleanups' except that it just removes the cleanups from
495
     the chain and does not call the specified functions.
496
 
497
   Some functions, e.g. `fputs_filtered()' or `error()', specify that
498
they "should not be called when cleanups are not in place".  This means
499
that any actions you need to reverse in the case of an error or
500
interruption must be on the cleanup chain before you call these
501
functions, since they might never return to your code (they `longjmp'
502
instead).
503
 
504
Wrapping Output Lines
505
=====================
506
 
507
   Output that goes through `printf_filtered' or `fputs_filtered' or
508
`fputs_demangled' needs only to have calls to `wrap_here' added in
509
places that would be good breaking points.  The utility routines will
510
take care of actually wrapping if the line width is exceeded.
511
 
512
   The argument to `wrap_here' is an indentation string which is
513
printed _only_ if the line breaks there.  This argument is saved away
514
and used later.  It must remain valid until the next call to
515
`wrap_here' or until a newline has been printed through the
516
`*_filtered' functions.  Don't pass in a local variable and then return!
517
 
518
   It is usually best to call `wrap_here' after printing a comma or
519
space.  If you call it before printing a space, make sure that your
520
indentation properly accounts for the leading space that will print if
521
the line wraps there.
522
 
523
   Any function or set of functions that produce filtered output must
524
finish by printing a newline, to flush the wrap buffer, before switching
525
to unfiltered (`printf') output.  Symbol reading routines that print
526
warnings are a good example.
527
 
528
GDB Coding Standards
529
====================
530
 
531
   GDB follows the GNU coding standards, as described in
532
`etc/standards.texi'.  This file is also available for anonymous FTP
533
from GNU archive sites.  GDB takes a strict interpretation of the
534
standard; in general, when the GNU standard recommends a practice but
535
does not require it, GDB requires it.
536
 
537
   GDB follows an additional set of coding standards specific to GDB,
538
as described in the following sections.
539
 
540
ISO-C
541
-----
542
 
543
   GDB assumes an ISO-C compliant compiler.
544
 
545
   GDB does not assume an ISO-C or POSIX compliant C library.
546
 
547
Memory Management
548
-----------------
549
 
550
   GDB does not use the functions `malloc', `realloc', `calloc', `free'
551
and `asprintf'.
552
 
553
   GDB uses the functions `xmalloc', `xrealloc' and `xcalloc' when
554
allocating memory.  Unlike `malloc' et.al.  these functions do not
555
return when the memory pool is empty.  Instead, they unwind the stack
556
using cleanups.  These functions return `NULL' when requested to
557
allocate a chunk of memory of size zero.
558
 
559
   _Pragmatics: By using these functions, the need to check every
560
memory allocation is removed.  These functions provide portable
561
behavior._
562
 
563
   GDB does not use the function `free'.
564
 
565
   GDB uses the function `xfree' to return memory to the memory pool.
566
Consistent with ISO-C, this function ignores a request to free a `NULL'
567
pointer.
568
 
569
   _Pragmatics: On some systems `free' fails when passed a `NULL'
570
pointer._
571
 
572
   GDB can use the non-portable function `alloca' for the allocation of
573
small temporary values (such as strings).
574
 
575
   _Pragmatics: This function is very non-portable.  Some systems
576
restrict the memory being allocated to no more than a few kilobytes._
577
 
578
   GDB uses the string function `xstrdup' and the print function
579
`xasprintf'.
580
 
581
   _Pragmatics: `asprintf' and `strdup' can fail.  Print functions such
582
as `sprintf' are very prone to buffer overflow errors._
583
 
584
Compiler Warnings
585
-----------------
586
 
587
   With few exceptions, developers should include the configuration
588
option `--enable-gdb-build-warnings=,-Werror' when building GDB.  The
589
exceptions are listed in the file `gdb/MAINTAINERS'.
590
 
591
   This option causes GDB (when built using GCC) to be compiled with a
592
carefully selected list of compiler warning flags.  Any warnings from
593
those flags being treated as errors.
594
 
595
   The current list of warning flags includes:
596
 
597
`-Wimplicit'
598
     Since GDB coding standard requires all functions to be declared
599
     using a prototype, the flag has the side effect of ensuring that
600
     prototyped functions are always visible with out resorting to
601
     `-Wstrict-prototypes'.
602
 
603
`-Wreturn-type'
604
     Such code often appears to work except on instruction set
605
     architectures that use register windows.
606
 
607
`-Wcomment'
608
 
609
`-Wtrigraphs'
610
 
611
`-Wformat'
612
     Since GDB uses the `format printf' attribute on all `printf' like
613
     functions this checks not just `printf' calls but also calls to
614
     functions such as `fprintf_unfiltered'.
615
 
616
`-Wparentheses'
617
     This warning includes uses of the assignment operator within an
618
     `if' statement.
619
 
620
`-Wpointer-arith'
621
 
622
`-Wuninitialized'
623
   _Pragmatics: Due to the way that GDB is implemented most functions
624
have unused parameters.  Consequently the warning `-Wunused-parameter'
625
is precluded from the list.  The macro `ATTRIBUTE_UNUSED' is not used
626
as it leads to false negatives -- it is not an error to have
627
`ATTRIBUTE_UNUSED' on a parameter that is being used.  The options
628
`-Wall' and `-Wunused' are also precluded because they both include
629
`-Wunused-parameter'._
630
 
631
   _Pragmatics: GDB has not simply accepted the warnings enabled by
632
`-Wall -Werror -W...'.  Instead it is selecting warnings when and where
633
their benefits can be demonstrated._
634
 
635
Formatting
636
----------
637
 
638
   The standard GNU recommendations for formatting must be followed
639
strictly.
640
 
641
   A function declaration should not have its name in column zero.  A
642
function definition should have its name in column zero.
643
 
644
     /* Declaration */
645
     static void foo (void);
646
     /* Definition */
647
     void
648
     foo (void)
649
     {
650
     }
651
 
652
   _Pragmatics: This simplifies scripting.  Function definitions can be
653
found using `^function-name'._
654
 
655
   There must be a space between a function or macro name and the
656
opening parenthesis of its argument list (except for macro definitions,
657
as required by C).  There must not be a space after an open
658
paren/bracket or before a close paren/bracket.
659
 
660
   While additional whitespace is generally helpful for reading, do not
661
use more than one blank line to separate blocks, and avoid adding
662
whitespace after the end of a program line (as of 1/99, some 600 lines
663
had whitespace after the semicolon).  Excess whitespace causes
664
difficulties for `diff' and `patch' utilities.
665
 
666
   Pointers are declared using the traditional K&R C style:
667
 
668
     void *foo;
669
 
670
and not:
671
 
672
     void * foo;
673
     void* foo;
674
 
675
Comments
676
--------
677
 
678
   The standard GNU requirements on comments must be followed strictly.
679
 
680
   Block comments must appear in the following form, with no `/*'- or
681
`*/'-only lines, and no leading `*':
682
 
683
     /* Wait for control to return from inferior to debugger.  If inferior
684
        gets a signal, we may decide to start it up again instead of
685
        returning.  That is why there is a loop in this function.  When
686
        this function actually returns it means the inferior should be left
687
        stopped and GDB should read more commands.  */
688
 
689
   (Note that this format is encouraged by Emacs; tabbing for a
690
multi-line comment works correctly, and `M-q' fills the block
691
consistently.)
692
 
693
   Put a blank line between the block comments preceding function or
694
variable definitions, and the definition itself.
695
 
696
   In general, put function-body comments on lines by themselves, rather
697
than trying to fit them into the 20 characters left at the end of a
698
line, since either the comment or the code will inevitably get longer
699
than will fit, and then somebody will have to move it anyhow.
700
 
701
C Usage
702
-------
703
 
704
   Code must not depend on the sizes of C data types, the format of the
705
host's floating point numbers, the alignment of anything, or the order
706
of evaluation of expressions.
707
 
708
   Use functions freely.  There are only a handful of compute-bound
709
areas in GDB that might be affected by the overhead of a function call,
710
mainly in symbol reading.  Most of GDB's performance is limited by the
711
target interface (whether serial line or system call).
712
 
713
   However, use functions with moderation.  A thousand one-line
714
functions are just as hard to understand as a single thousand-line
715
function.
716
 
717
   _Macros are bad, M'kay._
718
 
719
   Declarations like `struct foo *' should be used in preference to
720
declarations like `typedef struct foo { ... } *foo_ptr'.
721
 
722
Function Prototypes
723
-------------------
724
 
725
   Prototypes must be used when both _declaring_ and _defining_ a
726
function.  Prototypes for GDB functions must include both the argument
727
type and name, with the name matching that used in the actual function
728
definition.
729
 
730
   All external functions should have a declaration in a header file
731
that callers include, except for `_initialize_*' functions, which must
732
be external so that `init.c' construction works, but shouldn't be
733
visible to random source files.
734
 
735
   Where a source file needs a forward declaration of a static function,
736
that declaration must appear in a block near the top of the source file.
737
 
738
Internal Error Recovery
739
-----------------------
740
 
741
   During its execution, GDB can encounter two types of errors.  User
742
errors and internal errors.  User errors include not only a user
743
entering an incorrect command but also problems arising from corrupt
744
object files and system errors when interacting with the target.
745
Internal errors include situtations where GDB has detected, at run
746
time, a corrupt or erroneous situtation.
747
 
748
   When reporting an internal error, GDB uses `internal_error' and
749
`gdb_assert'.
750
 
751
   GDB must not call `abort' or `assert'.
752
 
753
   _Pragmatics: There is no `internal_warning' function.  Either the
754
code detected a user error, recovered from it and issued a `warning' or
755
the code failed to correctly recover from the user error and issued an
756
`internal_error'._
757
 
758
File Names
759
----------
760
 
761
   Any file used when building the core of GDB must be in lower case.
762
Any file used when building the core of GDB must be 8.3 unique.  These
763
requirements apply to both source and generated files.
764
 
765
   _Pragmatics: The core of GDB must be buildable on many platforms
766
including DJGPP and MacOS/HFS.  Every time an unfriendly file is
767
introduced to the build process both `Makefile.in' and `configure.in'
768
need to be modified accordingly.  Compare the convoluted conversion
769
process needed to transform `COPYING' into `copying.c' with the
770
conversion needed to transform `version.in' into `version.c'._
771
 
772
   Any file non 8.3 compliant file (that is not used when building the
773
core of GDB) must be added to `gdb/config/djgpp/fnchange.lst'.
774
 
775
   _Pragmatics: This is clearly a compromise._
776
 
777
   When GDB has a local version of a system header file (ex `string.h')
778
the file name based on the POSIX header prefixed with `gdb_'
779
(`gdb_string.h').
780
 
781
   For other files `-' is used as the separator.
782
 
783
Include Files
784
-------------
785
 
786
   All `.c' files should include `defs.h' first.
787
 
788
   All `.c' files should explicitly include the headers for any
789
declarations they refer to.  They should not rely on files being
790
included indirectly.
791
 
792
   With the exception of the global definitions supplied by `defs.h', a
793
header file should explictily include the header declaring any
794
`typedefs' et.al. it refers to.
795
 
796
   `extern' declarations should never appear in `.c' files.
797
 
798
   All include files should be wrapped in:
799
 
800
     #ifndef INCLUDE_FILE_NAME_H
801
     #define INCLUDE_FILE_NAME_H
802
     header body
803
     #endif
804
 
805
Clean Design and Portable Implementation
806
----------------------------------------
807
 
808
   In addition to getting the syntax right, there's the little question
809
of semantics.  Some things are done in certain ways in GDB because long
810
experience has shown that the more obvious ways caused various kinds of
811
trouble.
812
 
813
   You can't assume the byte order of anything that comes from a target
814
(including VALUEs, object files, and instructions).  Such things must
815
be byte-swapped using `SWAP_TARGET_AND_HOST' in GDB, or one of the swap
816
routines defined in `bfd.h', such as `bfd_get_32'.
817
 
818
   You can't assume that you know what interface is being used to talk
819
to the target system.  All references to the target must go through the
820
current `target_ops' vector.
821
 
822
   You can't assume that the host and target machines are the same
823
machine (except in the "native" support modules).  In particular, you
824
can't assume that the target machine's header files will be available
825
on the host machine.  Target code must bring along its own header files
826
- written from scratch or explicitly donated by their owner, to avoid
827
copyright problems.
828
 
829
   Insertion of new `#ifdef''s will be frowned upon.  It's much better
830
to write the code portably than to conditionalize it for various
831
systems.
832
 
833
   New `#ifdef''s which test for specific compilers or manufacturers or
834
operating systems are unacceptable.  All `#ifdef''s should test for
835
features.  The information about which configurations contain which
836
features should be segregated into the configuration files.  Experience
837
has proven far too often that a feature unique to one particular system
838
often creeps into other systems; and that a conditional based on some
839
predefined macro for your current system will become worthless over
840
time, as new versions of your system come out that behave differently
841
with regard to this feature.
842
 
843
   Adding code that handles specific architectures, operating systems,
844
target interfaces, or hosts, is not acceptable in generic code.
845
 
846
   One particularly notorious area where system dependencies tend to
847
creep in is handling of file names.  The mainline GDB code assumes
848
Posix semantics of file names: absolute file names begin with a forward
849
slash `/', slashes are used to separate leading directories,
850
case-sensitive file names.  These assumptions are not necessarily true
851
on non-Posix systems such as MS-Windows.  To avoid system-dependent
852
code where you need to take apart or construct a file name, use the
853
following portable macros:
854
 
855
`HAVE_DOS_BASED_FILE_SYSTEM'
856
     This preprocessing symbol is defined to a non-zero value on hosts
857
     whose filesystems belong to the MS-DOS/MS-Windows family.  Use this
858
     symbol to write conditional code which should only be compiled for
859
     such hosts.
860
 
861
`IS_DIR_SEPARATOR (C'
862
     Evaluates to a non-zero value if C is a directory separator
863
     character.  On Unix and GNU/Linux systems, only a slash `/' is
864
     such a character, but on Windows, both `/' and `\' will pass.
865
 
866
`IS_ABSOLUTE_PATH (FILE)'
867
     Evaluates to a non-zero value if FILE is an absolute file name.
868
     For Unix and GNU/Linux hosts, a name which begins with a slash `/'
869
     is absolute.  On DOS and Windows, `d:/foo' and `x:\bar' are also
870
     absolute file names.
871
 
872
`FILENAME_CMP (F1, F2)'
873
     Calls a function which compares file names F1 and F2 as
874
     appropriate for the underlying host filesystem.  For Posix systems,
875
     this simply calls `strcmp'; on case-insensitive filesystems it
876
     will call `strcasecmp' instead.
877
 
878
`DIRNAME_SEPARATOR'
879
     Evaluates to a character which separates directories in
880
     `PATH'-style lists, typically held in environment variables.  This
881
     character is `:' on Unix, `;' on DOS and Windows.
882
 
883
`SLASH_STRING'
884
     This evaluates to a constant string you should use to produce an
885
     absolute filename from leading directories and the file's basename.
886
     `SLASH_STRING' is `"/"' on most systems, but might be `"\\"' for
887
     some Windows-based ports.
888
 
889
   In addition to using these macros, be sure to use portable library
890
functions whenever possible.  For example, to extract a directory or a
891
basename part from a file name, use the `dirname' and `basename'
892
library functions (available in `libiberty' for platforms which don't
893
provide them), instead of searching for a slash with `strrchr'.
894
 
895
   Another way to generalize GDB along a particular interface is with an
896
attribute struct.  For example, GDB has been generalized to handle
897
multiple kinds of remote interfaces--not by `#ifdef's everywhere, but
898
by defining the `target_ops' structure and having a current target (as
899
well as a stack of targets below it, for memory references).  Whenever
900
something needs to be done that depends on which remote interface we are
901
using, a flag in the current target_ops structure is tested (e.g.,
902
`target_has_stack'), or a function is called through a pointer in the
903
current target_ops structure.  In this way, when a new remote interface
904
is added, only one module needs to be touched--the one that actually
905
implements the new remote interface.  Other examples of
906
attribute-structs are BFD access to multiple kinds of object file
907
formats, or GDB's access to multiple source languages.
908
 
909
   Please avoid duplicating code.  For example, in GDB 3.x all the code
910
interfacing between `ptrace' and the rest of GDB was duplicated in
911
`*-dep.c', and so changing something was very painful.  In GDB 4.x,
912
these have all been consolidated into `infptrace.c'.  `infptrace.c' can
913
deal with variations between systems the same way any system-independent
914
file would (hooks, `#if defined', etc.), and machines which are
915
radically different don't need to use `infptrace.c' at all.
916
 
917
   All debugging code must be controllable using the `set debug MODULE'
918
command.  Do not use `printf' to print trace messages.  Use
919
`fprintf_unfiltered(gdb_stdlog, ...'.  Do not use `#ifdef DEBUG'.
920
 
921

922
File: gdbint.info,  Node: Porting GDB,  Next: Testsuite,  Prev: Coding,  Up: Top
923
 
924
Porting GDB
925
***********
926
 
927
   Most of the work in making GDB compile on a new machine is in
928
specifying the configuration of the machine.  This is done in a
929
dizzying variety of header files and configuration scripts, which we
930
hope to make more sensible soon.  Let's say your new host is called an
931
XYZ (e.g.,  `sun4'), and its full three-part configuration name is
932
`ARCH-XVEND-XOS' (e.g., `sparc-sun-sunos4').  In particular:
933
 
934
   * In the top level directory, edit `config.sub' and add ARCH, XVEND,
935
     and XOS to the lists of supported architectures, vendors, and
936
     operating systems near the bottom of the file.  Also, add XYZ as
937
     an alias that maps to `ARCH-XVEND-XOS'.  You can test your changes
938
     by running
939
 
940
          ./config.sub XYZ
941
 
942
     and
943
 
944
          ./config.sub `ARCH-XVEND-XOS'
945
 
946
     which should both respond with `ARCH-XVEND-XOS' and no error
947
     messages.
948
 
949
     You need to port BFD, if that hasn't been done already.  Porting
950
     BFD is beyond the scope of this manual.
951
 
952
   * To configure GDB itself, edit `gdb/configure.host' to recognize
953
     your system and set `gdb_host' to XYZ, and (unless your desired
954
     target is already available) also edit `gdb/configure.tgt',
955
     setting `gdb_target' to something appropriate (for instance, XYZ).
956
 
957
   * Finally, you'll need to specify and define GDB's host-, native-,
958
     and target-dependent `.h' and `.c' files used for your
959
     configuration.
960
 
961
Configuring GDB for Release
962
===========================
963
 
964
   From the top level directory (containing `gdb', `bfd', `libiberty',
965
and so on):
966
 
967
     make -f Makefile.in gdb.tar.gz
968
 
969
This will properly configure, clean, rebuild any files that are
970
distributed pre-built (e.g. `c-exp.tab.c' or `refcard.ps'), and will
971
then make a tarfile.  (If the top level directory has already been
972
configured, you can just do `make gdb.tar.gz' instead.)
973
 
974
   This procedure requires:
975
 
976
   * symbolic links;
977
 
978
   * `makeinfo' (texinfo2 level);
979
 
980
   * TeX;
981
 
982
   * `dvips';
983
 
984
   * `yacc' or `bison'.
985
 
986
... and the usual slew of utilities (`sed', `tar', etc.).
987
 
988
TEMPORARY RELEASE PROCEDURE FOR DOCUMENTATION
989
---------------------------------------------
990
 
991
   `gdb.texinfo' is currently marked up using the texinfo-2 macros,
992
which are not yet a default for anything (but we have to start using
993
them sometime).
994
 
995
   For making paper, the only thing this implies is the right
996
generation of `texinfo.tex' needs to be included in the distribution.
997
 
998
   For making info files, however, rather than duplicating the texinfo2
999
distribution, generate `gdb-all.texinfo' locally, and include the files
1000
`gdb.info*' in the distribution.  Note the plural; `makeinfo' will
1001
split the document into one overall file and five or so included files.
1002
 
1003

1004
File: gdbint.info,  Node: Testsuite,  Next: Hints,  Prev: Porting GDB,  Up: Top
1005
 
1006
Testsuite
1007
*********
1008
 
1009
   The testsuite is an important component of the GDB package.  While
1010
it is always worthwhile to encourage user testing, in practice this is
1011
rarely sufficient; users typically use only a small subset of the
1012
available commands, and it has proven all too common for a change to
1013
cause a significant regression that went unnoticed for some time.
1014
 
1015
   The GDB testsuite uses the DejaGNU testing framework.  DejaGNU is
1016
built using `Tcl' and `expect'.  The tests themselves are calls to
1017
various `Tcl' procs; the framework runs all the procs and summarizes
1018
the passes and fails.
1019
 
1020
Using the Testsuite
1021
===================
1022
 
1023
   To run the testsuite, simply go to the GDB object directory (or to
1024
the testsuite's objdir) and type `make check'.  This just sets up some
1025
environment variables and invokes DejaGNU's `runtest' script.  While
1026
the testsuite is running, you'll get mentions of which test file is in
1027
use, and a mention of any unexpected passes or fails.  When the
1028
testsuite is finished, you'll get a summary that looks like this:
1029
 
1030
                     === gdb Summary ===
1031
 
1032
     # of expected passes            6016
1033
     # of unexpected failures        58
1034
     # of unexpected successes       5
1035
     # of expected failures          183
1036
     # of unresolved testcases       3
1037
     # of untested testcases         5
1038
 
1039
   The ideal test run consists of expected passes only; however, reality
1040
conspires to keep us from this ideal.  Unexpected failures indicate
1041
real problems, whether in GDB or in the testsuite.  Expected failures
1042
are still failures, but ones which have been decided are too hard to
1043
deal with at the time; for instance, a test case might work everywhere
1044
except on AIX, and there is no prospect of the AIX case being fixed in
1045
the near future.  Expected failures should not be added lightly, since
1046
you may be masking serious bugs in GDB.  Unexpected successes are
1047
expected fails that are passing for some reason, while unresolved and
1048
untested cases often indicate some minor catastrophe, such as the
1049
compiler being unable to deal with a test program.
1050
 
1051
   When making any significant change to GDB, you should run the
1052
testsuite before and after the change, to confirm that there are no
1053
regressions.  Note that truly complete testing would require that you
1054
run the testsuite with all supported configurations and a variety of
1055
compilers; however this is more than really necessary.  In many cases
1056
testing with a single configuration is sufficient.  Other useful
1057
options are to test one big-endian (Sparc) and one little-endian (x86)
1058
host, a cross config with a builtin simulator (powerpc-eabi, mips-elf),
1059
or a 64-bit host (Alpha).
1060
 
1061
   If you add new functionality to GDB, please consider adding tests
1062
for it as well; this way future GDB hackers can detect and fix their
1063
changes that break the functionality you added.  Similarly, if you fix
1064
a bug that was not previously reported as a test failure, please add a
1065
test case for it.  Some cases are extremely difficult to test, such as
1066
code that handles host OS failures or bugs in particular versions of
1067
compilers, and it's OK not to try to write tests for all of those.
1068
 
1069
Testsuite Organization
1070
======================
1071
 
1072
   The testsuite is entirely contained in `gdb/testsuite'.  While the
1073
testsuite includes some makefiles and configury, these are very minimal,
1074
and used for little besides cleaning up, since the tests themselves
1075
handle the compilation of the programs that GDB will run.  The file
1076
`testsuite/lib/gdb.exp' contains common utility procs useful for all
1077
GDB tests, while the directory `testsuite/config' contains
1078
configuration-specific files, typically used for special-purpose
1079
definitions of procs like `gdb_load' and `gdb_start'.
1080
 
1081
   The tests themselves are to be found in `testsuite/gdb.*' and
1082
subdirectories of those.  The names of the test files must always end
1083
with `.exp'.  DejaGNU collects the test files by wildcarding in the
1084
test directories, so both subdirectories and individual files get
1085
chosen and run in alphabetical order.
1086
 
1087
   The following table lists the main types of subdirectories and what
1088
they are for.  Since DejaGNU finds test files no matter where they are
1089
located, and since each test file sets up its own compilation and
1090
execution environment, this organization is simply for convenience and
1091
intelligibility.
1092
 
1093
`gdb.base'
1094
     This is the base testsuite.  The tests in it should apply to all
1095
     configurations of GDB (but generic native-only tests may live
1096
     here).  The test programs should be in the subset of C that is
1097
     valid K&R, ANSI/ISO, and C++ (`#ifdef's are allowed if necessary,
1098
     for instance for prototypes).
1099
 
1100
`gdb.LANG'
1101
     Language-specific tests for any language LANG besides C.  Examples
1102
     are `gdb.c++' and `gdb.java'.
1103
 
1104
`gdb.PLATFORM'
1105
     Non-portable tests.  The tests are specific to a specific
1106
     configuration (host or target), such as HP-UX or eCos.  Example is
1107
     `gdb.hp', for HP-UX.
1108
 
1109
`gdb.COMPILER'
1110
     Tests specific to a particular compiler.  As of this writing (June
1111
     1999), there aren't currently any groups of tests in this category
1112
     that couldn't just as sensibly be made platform-specific, but one
1113
     could imagine a `gdb.gcc', for tests of GDB's handling of GCC
1114
     extensions.
1115
 
1116
`gdb.SUBSYSTEM'
1117
     Tests that exercise a specific GDB subsystem in more depth.  For
1118
     instance, `gdb.disasm' exercises various disassemblers, while
1119
     `gdb.stabs' tests pathways through the stabs symbol reader.
1120
 
1121
Writing Tests
1122
=============
1123
 
1124
   In many areas, the GDB tests are already quite comprehensive; you
1125
should be able to copy existing tests to handle new cases.
1126
 
1127
   You should try to use `gdb_test' whenever possible, since it
1128
includes cases to handle all the unexpected errors that might happen.
1129
However, it doesn't cost anything to add new test procedures; for
1130
instance, `gdb.base/exprs.exp' defines a `test_expr' that calls
1131
`gdb_test' multiple times.
1132
 
1133
   Only use `send_gdb' and `gdb_expect' when absolutely necessary, such
1134
as when GDB has several valid responses to a command.
1135
 
1136
   The source language programs do _not_ need to be in a consistent
1137
style.  Since GDB is used to debug programs written in many different
1138
styles, it's worth having a mix of styles in the testsuite; for
1139
instance, some GDB bugs involving the display of source lines would
1140
never manifest themselves if the programs used GNU coding style
1141
uniformly.
1142
 
1143

1144
File: gdbint.info,  Node: Hints,  Next: Index,  Prev: Testsuite,  Up: Top
1145
 
1146
Hints
1147
*****
1148
 
1149
   Check the `README' file, it often has useful information that does
1150
not appear anywhere else in the directory.
1151
 
1152
* Menu:
1153
 
1154
* Getting Started::             Getting started working on GDB
1155
* Debugging GDB::               Debugging GDB with itself
1156
 
1157

1158
File: gdbint.info,  Node: Getting Started,  Up: Hints
1159
 
1160
Getting Started
1161
===============
1162
 
1163
   GDB is a large and complicated program, and if you first starting to
1164
work on it, it can be hard to know where to start.  Fortunately, if you
1165
know how to go about it, there are ways to figure out what is going on.
1166
 
1167
   This manual, the GDB Internals manual, has information which applies
1168
generally to many parts of GDB.
1169
 
1170
   Information about particular functions or data structures are
1171
located in comments with those functions or data structures.  If you
1172
run across a function or a global variable which does not have a
1173
comment correctly explaining what is does, this can be thought of as a
1174
bug in GDB; feel free to submit a bug report, with a suggested comment
1175
if you can figure out what the comment should say.  If you find a
1176
comment which is actually wrong, be especially sure to report that.
1177
 
1178
   Comments explaining the function of macros defined in host, target,
1179
or native dependent files can be in several places.  Sometimes they are
1180
repeated every place the macro is defined.  Sometimes they are where the
1181
macro is used.  Sometimes there is a header file which supplies a
1182
default definition of the macro, and the comment is there.  This manual
1183
also documents all the available macros.
1184
 
1185
   Start with the header files.  Once you have some idea of how GDB's
1186
internal symbol tables are stored (see `symtab.h', `gdbtypes.h'), you
1187
will find it much easier to understand the code which uses and creates
1188
those symbol tables.
1189
 
1190
   You may wish to process the information you are getting somehow, to
1191
enhance your understanding of it.  Summarize it, translate it to another
1192
language, add some (perhaps trivial or non-useful) feature to GDB, use
1193
the code to predict what a test case would do and write the test case
1194
and verify your prediction, etc.  If you are reading code and your eyes
1195
are starting to glaze over, this is a sign you need to use a more active
1196
approach.
1197
 
1198
   Once you have a part of GDB to start with, you can find more
1199
specifically the part you are looking for by stepping through each
1200
function with the `next' command.  Do not use `step' or you will
1201
quickly get distracted; when the function you are stepping through
1202
calls another function try only to get a big-picture understanding
1203
(perhaps using the comment at the beginning of the function being
1204
called) of what it does.  This way you can identify which of the
1205
functions being called by the function you are stepping through is the
1206
one which you are interested in.  You may need to examine the data
1207
structures generated at each stage, with reference to the comments in
1208
the header files explaining what the data structures are supposed to
1209
look like.
1210
 
1211
   Of course, this same technique can be used if you are just reading
1212
the code, rather than actually stepping through it.  The same general
1213
principle applies--when the code you are looking at calls something
1214
else, just try to understand generally what the code being called does,
1215
rather than worrying about all its details.
1216
 
1217
   A good place to start when tracking down some particular area is with
1218
a command which invokes that feature.  Suppose you want to know how
1219
single-stepping works.  As a GDB user, you know that the `step' command
1220
invokes single-stepping.  The command is invoked via command tables
1221
(see `command.h'); by convention the function which actually performs
1222
the command is formed by taking the name of the command and adding
1223
`_command', or in the case of an `info' subcommand, `_info'.  For
1224
example, the `step' command invokes the `step_command' function and the
1225
`info display' command invokes `display_info'.  When this convention is
1226
not followed, you might have to use `grep' or `M-x tags-search' in
1227
emacs, or run GDB on itself and set a breakpoint in `execute_command'.
1228
 
1229
   If all of the above fail, it may be appropriate to ask for
1230
information on `bug-gdb'.  But _never_ post a generic question like "I
1231
was wondering if anyone could give me some tips about understanding
1232
GDB"--if we had some magic secret we would put it in this manual.
1233
Suggestions for improving the manual are always welcome, of course.
1234
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.