Differences between revisions 1 and 2
Revision 1 as of 2013-08-20 23:42:00
Size: 3325
Editor: StanShebs
Comment: Import from gdbint.texinfo
Revision 2 as of 2013-09-01 17:04:37
Size: 4380
Comment: Made layout and typography consistent. Added details of architecture and frame cache obstacks.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''This page was produced by an automated import process, and may have formatting errors; feel free to fix.'' == libiberty ==
Line 3: Line 3:
=== libiberty === The ''libiberty'' library provides a set of functions and features that integrate and improve on functionality found in modern operating systems. Broadly speaking, such features can be divided into three groups:
 1. supplemental functions (functions that may be missing in some environments and operating systems);
 2. replacement functions (providing a uniform and easier to use interface for commonly used standard functions); and
 3. extensions (which provide additional functionality beyond standard functions).
Line 5: Line 8:
   GDB uses various features provided by the ''libiberty'' library, for instance the C++ demangler, the IEEE floating format support functions, the input options parser {{{getopt}}}, the obstack extension (see [[#Obstacks in GDB|Obstacks in GDB]]), and other functions.
Line 7: Line 10:
The {{{libiberty}}} library provides a set of functions and features that integrate and improve on functionality found in modern operating systems. Broadly speaking, such features can be divided into three groups: supplemental functions (functions that may be missing in some environments and operating systems), replacement functions (providing a uniform and easier to use interface for commonly used standard functions), and extensions (which provide additional functionality beyond standard functions). '''Note.''' ''libiberty'' is in part a reflection of the long ancestry of GCC, which predates such functionality being available elsewhere. There are now many other widely used free libraries offering this functionality in C, while C++ and its Standard Template Library also offer the same. Students of history are invited to consult the [[https://sourceware.org/gdb/mailing-lists/|mailing list archives]] for the many debates on the subject of support libraries for GNU tools.
Line 9: Line 12:
GDB uses various features provided by the {{{libiberty}}} library, for instance the C{{{++}}} demangler, the IEEE floating format support functions, the input options parser ‘{{{getopt}}}’, the ‘{{{obstack}}}’ extension, and other functions. [obstacks-in-GDB ] === Obstacks in GDB ===
Line 11: Line 14:
==== {{{obstacks}}} in GDB ==== The obstack mechanism provides a convenient way to allocate and free chunks of memory. Each obstack is a pool of memory that is managed like a stack. Objects (of any nature, size and alignment) are allocated and freed in a LIFO fashion on an obstack (see libiberty's documentation for a more detailed explanation of obstacks).
Line 13: Line 16:
   The most noticeable use of obstacks in GDB is in object files. There is an obstack associated with each internal representation of an object file. Lots of things get allocated on these obstacks: dictionary entries, blocks, blockvectors, symbols, minimal symbols, types, vectors of fundamental types, class fields of types, object files section lists, object files section offset lists, line tables, symbol tables, partial symbol tables, string tables, symbol table private data, macros tables, debug information sections and entries, import and export lists (som), unwind information (hppa), dwarf2 location expressions data. Plus various strings such as directory names strings, debug format strings, names of types.
Line 15: Line 18:
The obstack mechanism provides a convenient way to allocate and free chunks of memory. Each obstack is a pool of memory that is managed like a stack. Objects (of any nature, size and alignment) are allocated and freed in a LIFO fashion on an obstack (see {{{libiberty}}}’s documentation for a more detailed explanation of {{{obstacks}}}). There are also obstacks associated with each architecture (part of {{{struct gdbarch}}}) and with the stack frame cache.
Line 17: Line 20:
The most noticeable use of the {{{obstacks}}} in GDB is in object files. There is an obstack associated with each internal representation of an object file. Lots of things get allocated on these {{{obstacks}}}: dictionary entries, blocks, blockvectors, symbols, minimal symbols, types, vectors of fundamental types, class fields of types, object files section lists, object files section offset lists, line tables, symbol tables, partial symbol tables, string tables, symbol table private data, macros tables, debug information sections and entries, import and export lists (som), unwind information (hppa), dwarf2 location expressions data. Plus various strings such as directory names strings, debug format strings, names of types. An essential and convenient property of all data on obstacks is that memory for it gets allocated (with {{{obstack_alloc}}}) at various times during a debugging session, but it is released all at once using the {{{obstack_free}}} function. The {{{obstack_free}}} function takes a pointer to where in the stack it must start the deletion from (much like the cleanup chains have a pointer to where to start the cleanups). Because of the stack like structure of the {{{obstacks}}}, this allows to free only a top portion of the obstack. There are a few instances in GDB where such thing happens. Calls to {{{obstack_free}}} are done after some local data is allocated to the obstack. Only the local data is deleted from the obstack. Of course this assumes that nothing between the {{{obstack_alloc}}} and the {{{obstack_free}}} allocates anything else on the same obstack. For this reason it is best and safest to use temporary obstacks.
Line 19: Line 22:
An essential and convenient property of all data on {{{obstacks}}} is that memory for it gets allocated (with {{{obstack_alloc}}}) at various times during a debugging session, but it is released all at once using the {{{obstack_free}}} function. The {{{obstack_free}}} function takes a pointer to where in the stack it must start the deletion from (much like the cleanup chains have a pointer to where to start the cleanups). Because of the stack like structure of the {{{obstacks}}}, this allows to free only a top portion of the obstack. There are a few instances in GDB where such thing happens. Calls to {{{obstack_free}}} are done after some local data is allocated to the obstack. Only the local data is deleted from the obstack. Of course this assumes that nothing between the {{{obstack_alloc}}} and the {{{obstack_free}}} allocates anything else on the same obstack. For this reason it is best and safest to use temporary {{{obstacks}}}. Releasing the whole obstack is also not safe ''per se''. It is safe only under the condition that we know the obstack's memory is no longer needed. In GDB we get rid of the obstacks only when we get rid of the whole objfile(s), for instance upon reading a new symbol file.
Line 21: Line 24:
Releasing the whole obstack is also not safe per se. It is safe only under the condition that we know the {{{obstacks}}} memory is no longer needed. In GDB we get rid of the {{{obstacks}}} only when we get rid of the whole objfile(s), for instance upon reading a new symbol file. GDB provides a number of convenience functions and macros wrapping the standard {{{obstack_alloc}}} function. For example the function {{{gdbarch_obstack_zalloc}}} and macros {{{GDBARCH_OBSTACK_CALLOC}}} and {{{GDBARCH_OBSTACK_ZALLOC}}} are defined in [[https://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdbarch.h?cvsroot=src|gdbarch.h]] to simplify allocations on the GDB architecture obstack and the function {{{frame_obstack_zalloc}}} and macros {{{FRAME_OBSTACK_CALLOC}}} and {{{FRAME_OBSTACK_ZALLOC}}} are defined in [[https://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/frame.h?cvsroot=src|frame.h]] to simplify allocations on the frame cache obstack.

libiberty

The libiberty library provides a set of functions and features that integrate and improve on functionality found in modern operating systems. Broadly speaking, such features can be divided into three groups:

  1. supplemental functions (functions that may be missing in some environments and operating systems);
  2. replacement functions (providing a uniform and easier to use interface for commonly used standard functions); and
  3. extensions (which provide additional functionality beyond standard functions).

GDB uses various features provided by the libiberty library, for instance the C++ demangler, the IEEE floating format support functions, the input options parser getopt, the obstack extension (see Obstacks in GDB), and other functions.

Note. libiberty is in part a reflection of the long ancestry of GCC, which predates such functionality being available elsewhere. There are now many other widely used free libraries offering this functionality in C, while C++ and its Standard Template Library also offer the same. Students of history are invited to consult the mailing list archives for the many debates on the subject of support libraries for GNU tools.

Obstacks in GDB

The obstack mechanism provides a convenient way to allocate and free chunks of memory. Each obstack is a pool of memory that is managed like a stack. Objects (of any nature, size and alignment) are allocated and freed in a LIFO fashion on an obstack (see libiberty's documentation for a more detailed explanation of obstacks).

The most noticeable use of obstacks in GDB is in object files. There is an obstack associated with each internal representation of an object file. Lots of things get allocated on these obstacks: dictionary entries, blocks, blockvectors, symbols, minimal symbols, types, vectors of fundamental types, class fields of types, object files section lists, object files section offset lists, line tables, symbol tables, partial symbol tables, string tables, symbol table private data, macros tables, debug information sections and entries, import and export lists (som), unwind information (hppa), dwarf2 location expressions data. Plus various strings such as directory names strings, debug format strings, names of types.

There are also obstacks associated with each architecture (part of struct gdbarch) and with the stack frame cache.

An essential and convenient property of all data on obstacks is that memory for it gets allocated (with obstack_alloc) at various times during a debugging session, but it is released all at once using the obstack_free function. The obstack_free function takes a pointer to where in the stack it must start the deletion from (much like the cleanup chains have a pointer to where to start the cleanups). Because of the stack like structure of the obstacks, this allows to free only a top portion of the obstack. There are a few instances in GDB where such thing happens. Calls to obstack_free are done after some local data is allocated to the obstack. Only the local data is deleted from the obstack. Of course this assumes that nothing between the obstack_alloc and the obstack_free allocates anything else on the same obstack. For this reason it is best and safest to use temporary obstacks.

Releasing the whole obstack is also not safe per se. It is safe only under the condition that we know the obstack's memory is no longer needed. In GDB we get rid of the obstacks only when we get rid of the whole objfile(s), for instance upon reading a new symbol file.

GDB provides a number of convenience functions and macros wrapping the standard obstack_alloc function. For example the function gdbarch_obstack_zalloc and macros GDBARCH_OBSTACK_CALLOC and GDBARCH_OBSTACK_ZALLOC are defined in gdbarch.h to simplify allocations on the GDB architecture obstack and the function frame_obstack_zalloc and macros FRAME_OBSTACK_CALLOC and FRAME_OBSTACK_ZALLOC are defined in frame.h to simplify allocations on the frame cache obstack.

None: Internals libiberty (last edited 2013-09-01 17:04:37 by JeremyBennett)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.