gty.texi 26 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706
  1. @c Copyright (C) 2002-2015 Free Software Foundation, Inc.
  2. @c This is part of the GCC manual.
  3. @c For copying conditions, see the file gcc.texi.
  4. @node Type Information
  5. @chapter Memory Management and Type Information
  6. @cindex GGC
  7. @findex GTY
  8. GCC uses some fairly sophisticated memory management techniques, which
  9. involve determining information about GCC's data structures from GCC's
  10. source code and using this information to perform garbage collection and
  11. implement precompiled headers.
  12. A full C++ parser would be too complicated for this task, so a limited
  13. subset of C++ is interpreted and special markers are used to determine
  14. what parts of the source to look at. All @code{struct}, @code{union}
  15. and @code{template} structure declarations that define data structures
  16. that are allocated under control of the garbage collector must be
  17. marked. All global variables that hold pointers to garbage-collected
  18. memory must also be marked. Finally, all global variables that need
  19. to be saved and restored by a precompiled header must be marked. (The
  20. precompiled header mechanism can only save static variables if they're
  21. scalar. Complex data structures must be allocated in garbage-collected
  22. memory to be saved in a precompiled header.)
  23. The full format of a marker is
  24. @smallexample
  25. GTY (([@var{option}] [(@var{param})], [@var{option}] [(@var{param})] @dots{}))
  26. @end smallexample
  27. @noindent
  28. but in most cases no options are needed. The outer double parentheses
  29. are still necessary, though: @code{GTY(())}. Markers can appear:
  30. @itemize @bullet
  31. @item
  32. In a structure definition, before the open brace;
  33. @item
  34. In a global variable declaration, after the keyword @code{static} or
  35. @code{extern}; and
  36. @item
  37. In a structure field definition, before the name of the field.
  38. @end itemize
  39. Here are some examples of marking simple data structures and globals.
  40. @smallexample
  41. struct GTY(()) @var{tag}
  42. @{
  43. @var{fields}@dots{}
  44. @};
  45. typedef struct GTY(()) @var{tag}
  46. @{
  47. @var{fields}@dots{}
  48. @} *@var{typename};
  49. static GTY(()) struct @var{tag} *@var{list}; /* @r{points to GC memory} */
  50. static GTY(()) int @var{counter}; /* @r{save counter in a PCH} */
  51. @end smallexample
  52. The parser understands simple typedefs such as
  53. @code{typedef struct @var{tag} *@var{name};} and
  54. @code{typedef int @var{name};}.
  55. These don't need to be marked.
  56. Since @code{gengtype}'s understanding of C++ is limited, there are
  57. several constructs and declarations that are not supported inside
  58. classes/structures marked for automatic GC code generation. The
  59. following C++ constructs produce a @code{gengtype} error on
  60. structures/classes marked for automatic GC code generation:
  61. @itemize @bullet
  62. @item
  63. Type definitions inside classes/structures are not supported.
  64. @item
  65. Enumerations inside classes/structures are not supported.
  66. @end itemize
  67. If you have a class or structure using any of the above constructs,
  68. you need to mark that class as @code{GTY ((user))} and provide your
  69. own marking routines (see section @ref{User GC} for details).
  70. It is always valid to include function definitions inside classes.
  71. Those are always ignored by @code{gengtype}, as it only cares about
  72. data members.
  73. @menu
  74. * GTY Options:: What goes inside a @code{GTY(())}.
  75. * Inheritance and GTY:: Adding GTY to a class hierarchy.
  76. * User GC:: Adding user-provided GC marking routines.
  77. * GGC Roots:: Making global variables GGC roots.
  78. * Files:: How the generated files work.
  79. * Invoking the garbage collector:: How to invoke the garbage collector.
  80. * Troubleshooting:: When something does not work as expected.
  81. @end menu
  82. @node GTY Options
  83. @section The Inside of a @code{GTY(())}
  84. Sometimes the C code is not enough to fully describe the type
  85. structure. Extra information can be provided with @code{GTY} options
  86. and additional markers. Some options take a parameter, which may be
  87. either a string or a type name, depending on the parameter. If an
  88. option takes no parameter, it is acceptable either to omit the
  89. parameter entirely, or to provide an empty string as a parameter. For
  90. example, @code{@w{GTY ((skip))}} and @code{@w{GTY ((skip ("")))}} are
  91. equivalent.
  92. When the parameter is a string, often it is a fragment of C code. Four
  93. special escapes may be used in these strings, to refer to pieces of
  94. the data structure being marked:
  95. @cindex % in GTY option
  96. @table @code
  97. @item %h
  98. The current structure.
  99. @item %1
  100. The structure that immediately contains the current structure.
  101. @item %0
  102. The outermost structure that contains the current structure.
  103. @item %a
  104. A partial expression of the form @code{[i1][i2]@dots{}} that indexes
  105. the array item currently being marked.
  106. @end table
  107. For instance, suppose that you have a structure of the form
  108. @smallexample
  109. struct A @{
  110. @dots{}
  111. @};
  112. struct B @{
  113. struct A foo[12];
  114. @};
  115. @end smallexample
  116. @noindent
  117. and @code{b} is a variable of type @code{struct B}. When marking
  118. @samp{b.foo[11]}, @code{%h} would expand to @samp{b.foo[11]},
  119. @code{%0} and @code{%1} would both expand to @samp{b}, and @code{%a}
  120. would expand to @samp{[11]}.
  121. As in ordinary C, adjacent strings will be concatenated; this is
  122. helpful when you have a complicated expression.
  123. @smallexample
  124. @group
  125. GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
  126. " ? TYPE_NEXT_VARIANT (&%h.generic)"
  127. " : TREE_CHAIN (&%h.generic)")))
  128. @end group
  129. @end smallexample
  130. The available options are:
  131. @table @code
  132. @findex length
  133. @item length ("@var{expression}")
  134. There are two places the type machinery will need to be explicitly told
  135. the length of an array of non-atomic objects. The first case is when a
  136. structure ends in a variable-length array, like this:
  137. @smallexample
  138. struct GTY(()) rtvec_def @{
  139. int num_elem; /* @r{number of elements} */
  140. rtx GTY ((length ("%h.num_elem"))) elem[1];
  141. @};
  142. @end smallexample
  143. In this case, the @code{length} option is used to override the specified
  144. array length (which should usually be @code{1}). The parameter of the
  145. option is a fragment of C code that calculates the length.
  146. The second case is when a structure or a global variable contains a
  147. pointer to an array, like this:
  148. @smallexample
  149. struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter;
  150. @end smallexample
  151. In this case, @code{iter} has been allocated by writing something like
  152. @smallexample
  153. x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse);
  154. @end smallexample
  155. and the @code{collapse} provides the length of the field.
  156. This second use of @code{length} also works on global variables, like:
  157. @verbatim
  158. static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
  159. @end verbatim
  160. Note that the @code{length} option is only meant for use with arrays of
  161. non-atomic objects, that is, objects that contain pointers pointing to
  162. other GTY-managed objects. For other GC-allocated arrays and strings
  163. you should use @code{atomic}.
  164. @findex skip
  165. @item skip
  166. If @code{skip} is applied to a field, the type machinery will ignore it.
  167. This is somewhat dangerous; the only safe use is in a union when one
  168. field really isn't ever used.
  169. @findex for_user
  170. Use this to mark types that need to be marked by user gc routines, but are not
  171. refered to in a template argument. So if you have some user gc type T1 and a
  172. non user gc type T2 you can give T2 the for_user option so that the marking
  173. functions for T1 can call non mangled functions to mark T2.
  174. @findex desc
  175. @findex tag
  176. @findex default
  177. @item desc ("@var{expression}")
  178. @itemx tag ("@var{constant}")
  179. @itemx default
  180. The type machinery needs to be told which field of a @code{union} is
  181. currently active. This is done by giving each field a constant
  182. @code{tag} value, and then specifying a discriminator using @code{desc}.
  183. The value of the expression given by @code{desc} is compared against
  184. each @code{tag} value, each of which should be different. If no
  185. @code{tag} is matched, the field marked with @code{default} is used if
  186. there is one, otherwise no field in the union will be marked.
  187. In the @code{desc} option, the ``current structure'' is the union that
  188. it discriminates. Use @code{%1} to mean the structure containing it.
  189. There are no escapes available to the @code{tag} option, since it is a
  190. constant.
  191. For example,
  192. @smallexample
  193. struct GTY(()) tree_binding
  194. @{
  195. struct tree_common common;
  196. union tree_binding_u @{
  197. tree GTY ((tag ("0"))) scope;
  198. struct cp_binding_level * GTY ((tag ("1"))) level;
  199. @} GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
  200. tree value;
  201. @};
  202. @end smallexample
  203. In this example, the value of BINDING_HAS_LEVEL_P when applied to a
  204. @code{struct tree_binding *} is presumed to be 0 or 1. If 1, the type
  205. mechanism will treat the field @code{level} as being present and if 0,
  206. will treat the field @code{scope} as being present.
  207. The @code{desc} and @code{tag} options can also be used for inheritance
  208. to denote which subclass an instance is. See @ref{Inheritance and GTY}
  209. for more information.
  210. @findex cache
  211. @item cache
  212. When the @code{cache} option is applied to a global variable gt_clear_cache is
  213. called on that variable between the mark and sweep phases of garbage
  214. collection. The gt_clear_cache function is free to mark blocks as used, or to
  215. clear pointers in the variable.
  216. @findex deletable
  217. @item deletable
  218. @code{deletable}, when applied to a global variable, indicates that when
  219. garbage collection runs, there's no need to mark anything pointed to
  220. by this variable, it can just be set to @code{NULL} instead. This is used
  221. to keep a list of free structures around for re-use.
  222. @findex mark_hook
  223. @item mark_hook ("@var{hook-routine-name}")
  224. If provided for a structure or union type, the given
  225. @var{hook-routine-name} (between double-quotes) is the name of a
  226. routine called when the garbage collector has just marked the data as
  227. reachable. This routine should not change the data, or call any ggc
  228. routine. Its only argument is a pointer to the just marked (const)
  229. structure or union.
  230. @findex maybe_undef
  231. @item maybe_undef
  232. When applied to a field, @code{maybe_undef} indicates that it's OK if
  233. the structure that this fields points to is never defined, so long as
  234. this field is always @code{NULL}. This is used to avoid requiring
  235. backends to define certain optional structures. It doesn't work with
  236. language frontends.
  237. @findex nested_ptr
  238. @item nested_ptr (@var{type}, "@var{to expression}", "@var{from expression}")
  239. The type machinery expects all pointers to point to the start of an
  240. object. Sometimes for abstraction purposes it's convenient to have
  241. a pointer which points inside an object. So long as it's possible to
  242. convert the original object to and from the pointer, such pointers
  243. can still be used. @var{type} is the type of the original object,
  244. the @var{to expression} returns the pointer given the original object,
  245. and the @var{from expression} returns the original object given
  246. the pointer. The pointer will be available using the @code{%h}
  247. escape.
  248. @findex chain_next
  249. @findex chain_prev
  250. @findex chain_circular
  251. @item chain_next ("@var{expression}")
  252. @itemx chain_prev ("@var{expression}")
  253. @itemx chain_circular ("@var{expression}")
  254. It's helpful for the type machinery to know if objects are often
  255. chained together in long lists; this lets it generate code that uses
  256. less stack space by iterating along the list instead of recursing down
  257. it. @code{chain_next} is an expression for the next item in the list,
  258. @code{chain_prev} is an expression for the previous item. For singly
  259. linked lists, use only @code{chain_next}; for doubly linked lists, use
  260. both. The machinery requires that taking the next item of the
  261. previous item gives the original item. @code{chain_circular} is similar
  262. to @code{chain_next}, but can be used for circular single linked lists.
  263. @findex reorder
  264. @item reorder ("@var{function name}")
  265. Some data structures depend on the relative ordering of pointers. If
  266. the precompiled header machinery needs to change that ordering, it
  267. will call the function referenced by the @code{reorder} option, before
  268. changing the pointers in the object that's pointed to by the field the
  269. option applies to. The function must take four arguments, with the
  270. signature @samp{@w{void *, void *, gt_pointer_operator, void *}}.
  271. The first parameter is a pointer to the structure that contains the
  272. object being updated, or the object itself if there is no containing
  273. structure. The second parameter is a cookie that should be ignored.
  274. The third parameter is a routine that, given a pointer, will update it
  275. to its correct new value. The fourth parameter is a cookie that must
  276. be passed to the second parameter.
  277. PCH cannot handle data structures that depend on the absolute values
  278. of pointers. @code{reorder} functions can be expensive. When
  279. possible, it is better to depend on properties of the data, like an ID
  280. number or the hash of a string instead.
  281. @findex atomic
  282. @item atomic
  283. The @code{atomic} option can only be used with pointers. It informs
  284. the GC machinery that the memory that the pointer points to does not
  285. contain any pointers, and hence it should be treated by the GC and PCH
  286. machinery as an ``atomic'' block of memory that does not need to be
  287. examined when scanning memory for pointers. In particular, the
  288. machinery will not scan that memory for pointers to mark them as
  289. reachable (when marking pointers for GC) or to relocate them (when
  290. writing a PCH file).
  291. The @code{atomic} option differs from the @code{skip} option.
  292. @code{atomic} keeps the memory under Garbage Collection, but makes the
  293. GC ignore the contents of the memory. @code{skip} is more drastic in
  294. that it causes the pointer and the memory to be completely ignored by
  295. the Garbage Collector. So, memory marked as @code{atomic} is
  296. automatically freed when no longer reachable, while memory marked as
  297. @code{skip} is not.
  298. The @code{atomic} option must be used with great care, because all
  299. sorts of problem can occur if used incorrectly, that is, if the memory
  300. the pointer points to does actually contain a pointer.
  301. Here is an example of how to use it:
  302. @smallexample
  303. struct GTY(()) my_struct @{
  304. int number_of_elements;
  305. unsigned int * GTY ((atomic)) elements;
  306. @};
  307. @end smallexample
  308. In this case, @code{elements} is a pointer under GC, and the memory it
  309. points to needs to be allocated using the Garbage Collector, and will
  310. be freed automatically by the Garbage Collector when it is no longer
  311. referenced. But the memory that the pointer points to is an array of
  312. @code{unsigned int} elements, and the GC must not try to scan it to
  313. find pointers to mark or relocate, which is why it is marked with the
  314. @code{atomic} option.
  315. Note that, currently, global variables can not be marked with
  316. @code{atomic}; only fields of a struct can. This is a known
  317. limitation. It would be useful to be able to mark global pointers
  318. with @code{atomic} to make the PCH machinery aware of them so that
  319. they are saved and restored correctly to PCH files.
  320. @findex special
  321. @item special ("@var{name}")
  322. The @code{special} option is used to mark types that have to be dealt
  323. with by special case machinery. The parameter is the name of the
  324. special case. See @file{gengtype.c} for further details. Avoid
  325. adding new special cases unless there is no other alternative.
  326. @findex user
  327. @item user
  328. The @code{user} option indicates that the code to mark structure
  329. fields is completely handled by user-provided routines. See section
  330. @ref{User GC} for details on what functions need to be provided.
  331. @end table
  332. @node Inheritance and GTY
  333. @section Support for inheritance
  334. gengtype has some support for simple class hierarchies. You can use
  335. this to have gengtype autogenerate marking routines, provided:
  336. @itemize @bullet
  337. @item
  338. There must be a concrete base class, with a discriminator expression
  339. that can be used to identify which subclass an instance is.
  340. @item
  341. Only single inheritance is used.
  342. @item
  343. None of the classes within the hierarchy are templates.
  344. @end itemize
  345. If your class hierarchy does not fit in this pattern, you must use
  346. @ref{User GC} instead.
  347. The base class and its discriminator must be identified using the ``desc''
  348. option. Each concrete subclass must use the ``tag'' option to identify
  349. which value of the discriminator it corresponds to.
  350. Every class in the hierarchy must have a @code{GTY(())} marker, as
  351. gengtype will only attempt to parse classes that have such a marker
  352. @footnote{Classes lacking such a marker will not be identified as being
  353. part of the hierarchy, and so the marking routines will not handle them,
  354. leading to a assertion failure within the marking routines due to an
  355. unknown tag value (assuming that assertions are enabled).}.
  356. @smallexample
  357. class GTY((desc("%h.kind"), tag("0"))) example_base
  358. @{
  359. public:
  360. int kind;
  361. tree a;
  362. @};
  363. class GTY((tag("1")) some_subclass : public example_base
  364. @{
  365. public:
  366. tree b;
  367. @};
  368. class GTY((tag("2")) some_other_subclass : public example_base
  369. @{
  370. public:
  371. tree c;
  372. @};
  373. @end smallexample
  374. The generated marking routines for the above will contain a ``switch''
  375. on ``kind'', visiting all appropriate fields. For example, if kind is
  376. 2, it will cast to ``some_other_subclass'' and visit fields a, b, and c.
  377. @node User GC
  378. @section Support for user-provided GC marking routines
  379. @cindex user gc
  380. The garbage collector supports types for which no automatic marking
  381. code is generated. For these types, the user is required to provide
  382. three functions: one to act as a marker for garbage collection, and
  383. two functions to act as marker and pointer walker for pre-compiled
  384. headers.
  385. Given a structure @code{struct GTY((user)) my_struct}, the following functions
  386. should be defined to mark @code{my_struct}:
  387. @smallexample
  388. void gt_ggc_mx (my_struct *p)
  389. @{
  390. /* This marks field 'fld'. */
  391. gt_ggc_mx (p->fld);
  392. @}
  393. void gt_pch_nx (my_struct *p)
  394. @{
  395. /* This marks field 'fld'. */
  396. gt_pch_nx (tp->fld);
  397. @}
  398. void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie)
  399. @{
  400. /* For every field 'fld', call the given pointer operator. */
  401. op (&(tp->fld), cookie);
  402. @}
  403. @end smallexample
  404. In general, each marker @code{M} should call @code{M} for every
  405. pointer field in the structure. Fields that are not allocated in GC
  406. or are not pointers must be ignored.
  407. For embedded lists (e.g., structures with a @code{next} or @code{prev}
  408. pointer), the marker must follow the chain and mark every element in
  409. it.
  410. Note that the rules for the pointer walker @code{gt_pch_nx (my_struct
  411. *, gt_pointer_operator, void *)} are slightly different. In this
  412. case, the operation @code{op} must be applied to the @emph{address} of
  413. every pointer field.
  414. @subsection User-provided marking routines for template types
  415. When a template type @code{TP} is marked with @code{GTY}, all
  416. instances of that type are considered user-provided types. This means
  417. that the individual instances of @code{TP} do not need to be marked
  418. with @code{GTY}. The user needs to provide template functions to mark
  419. all the fields of the type.
  420. The following code snippets represent all the functions that need to
  421. be provided. Note that type @code{TP} may reference to more than one
  422. type. In these snippets, there is only one type @code{T}, but there
  423. could be more.
  424. @smallexample
  425. template<typename T>
  426. void gt_ggc_mx (TP<T> *tp)
  427. @{
  428. extern void gt_ggc_mx (T&);
  429. /* This marks field 'fld' of type 'T'. */
  430. gt_ggc_mx (tp->fld);
  431. @}
  432. template<typename T>
  433. void gt_pch_nx (TP<T> *tp)
  434. @{
  435. extern void gt_pch_nx (T&);
  436. /* This marks field 'fld' of type 'T'. */
  437. gt_pch_nx (tp->fld);
  438. @}
  439. template<typename T>
  440. void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie)
  441. @{
  442. /* For every field 'fld' of 'tp' with type 'T *', call the given
  443. pointer operator. */
  444. op (&(tp->fld), cookie);
  445. @}
  446. template<typename T>
  447. void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie)
  448. @{
  449. extern void gt_pch_nx (T *, gt_pointer_operator, void *);
  450. /* For every field 'fld' of 'tp' with type 'T', call the pointer
  451. walker for all the fields of T. */
  452. gt_pch_nx (&(tp->fld), op, cookie);
  453. @}
  454. @end smallexample
  455. Support for user-defined types is currently limited. The following
  456. restrictions apply:
  457. @enumerate
  458. @item Type @code{TP} and all the argument types @code{T} must be
  459. marked with @code{GTY}.
  460. @item Type @code{TP} can only have type names in its argument list.
  461. @item The pointer walker functions are different for @code{TP<T>} and
  462. @code{TP<T *>}. In the case of @code{TP<T>}, references to
  463. @code{T} must be handled by calling @code{gt_pch_nx} (which
  464. will, in turn, walk all the pointers inside fields of @code{T}).
  465. In the case of @code{TP<T *>}, references to @code{T *} must be
  466. handled by calling the @code{op} function on the address of the
  467. pointer (see the code snippets above).
  468. @end enumerate
  469. @node GGC Roots
  470. @section Marking Roots for the Garbage Collector
  471. @cindex roots, marking
  472. @cindex marking roots
  473. In addition to keeping track of types, the type machinery also locates
  474. the global variables (@dfn{roots}) that the garbage collector starts
  475. at. Roots must be declared using one of the following syntaxes:
  476. @itemize @bullet
  477. @item
  478. @code{extern GTY(([@var{options}])) @var{type} @var{name};}
  479. @item
  480. @code{static GTY(([@var{options}])) @var{type} @var{name};}
  481. @end itemize
  482. @noindent
  483. The syntax
  484. @itemize @bullet
  485. @item
  486. @code{GTY(([@var{options}])) @var{type} @var{name};}
  487. @end itemize
  488. @noindent
  489. is @emph{not} accepted. There should be an @code{extern} declaration
  490. of such a variable in a header somewhere---mark that, not the
  491. definition. Or, if the variable is only used in one file, make it
  492. @code{static}.
  493. @node Files
  494. @section Source Files Containing Type Information
  495. @cindex generated files
  496. @cindex files, generated
  497. Whenever you add @code{GTY} markers to a source file that previously
  498. had none, or create a new source file containing @code{GTY} markers,
  499. there are three things you need to do:
  500. @enumerate
  501. @item
  502. You need to add the file to the list of source files the type
  503. machinery scans. There are four cases:
  504. @enumerate a
  505. @item
  506. For a back-end file, this is usually done
  507. automatically; if not, you should add it to @code{target_gtfiles} in
  508. the appropriate port's entries in @file{config.gcc}.
  509. @item
  510. For files shared by all front ends, add the filename to the
  511. @code{GTFILES} variable in @file{Makefile.in}.
  512. @item
  513. For files that are part of one front end, add the filename to the
  514. @code{gtfiles} variable defined in the appropriate
  515. @file{config-lang.in}.
  516. Headers should appear before non-headers in this list.
  517. @item
  518. For files that are part of some but not all front ends, add the
  519. filename to the @code{gtfiles} variable of @emph{all} the front ends
  520. that use it.
  521. @end enumerate
  522. @item
  523. If the file was a header file, you'll need to check that it's included
  524. in the right place to be visible to the generated files. For a back-end
  525. header file, this should be done automatically. For a front-end header
  526. file, it needs to be included by the same file that includes
  527. @file{gtype-@var{lang}.h}. For other header files, it needs to be
  528. included in @file{gtype-desc.c}, which is a generated file, so add it to
  529. @code{ifiles} in @code{open_base_file} in @file{gengtype.c}.
  530. For source files that aren't header files, the machinery will generate a
  531. header file that should be included in the source file you just changed.
  532. The file will be called @file{gt-@var{path}.h} where @var{path} is the
  533. pathname relative to the @file{gcc} directory with slashes replaced by
  534. @verb{|-|}, so for example the header file to be included in
  535. @file{cp/parser.c} is called @file{gt-cp-parser.c}. The
  536. generated header file should be included after everything else in the
  537. source file. Don't forget to mention this file as a dependency in the
  538. @file{Makefile}!
  539. @end enumerate
  540. For language frontends, there is another file that needs to be included
  541. somewhere. It will be called @file{gtype-@var{lang}.h}, where
  542. @var{lang} is the name of the subdirectory the language is contained in.
  543. Plugins can add additional root tables. Run the @code{gengtype}
  544. utility in plugin mode as @code{gengtype -P pluginout.h @var{source-dir}
  545. @var{file-list} @var{plugin*.c}} with your plugin files
  546. @var{plugin*.c} using @code{GTY} to generate the @var{pluginout.h} file.
  547. The GCC build tree is needed to be present in that mode.
  548. @node Invoking the garbage collector
  549. @section How to invoke the garbage collector
  550. @cindex garbage collector, invocation
  551. @findex ggc_collect
  552. The GCC garbage collector GGC is only invoked explicitly. In contrast
  553. with many other garbage collectors, it is not implicitly invoked by
  554. allocation routines when a lot of memory has been consumed. So the
  555. only way to have GGC reclaim storage is to call the @code{ggc_collect}
  556. function explicitly. This call is an expensive operation, as it may
  557. have to scan the entire heap. Beware that local variables (on the GCC
  558. call stack) are not followed by such an invocation (as many other
  559. garbage collectors do): you should reference all your data from static
  560. or external @code{GTY}-ed variables, and it is advised to call
  561. @code{ggc_collect} with a shallow call stack. The GGC is an exact mark
  562. and sweep garbage collector (so it does not scan the call stack for
  563. pointers). In practice GCC passes don't often call @code{ggc_collect}
  564. themselves, because it is called by the pass manager between passes.
  565. At the time of the @code{ggc_collect} call all pointers in the GC-marked
  566. structures must be valid or @code{NULL}. In practice this means that
  567. there should not be uninitialized pointer fields in the structures even
  568. if your code never reads or writes those fields at a particular
  569. instance. One way to ensure this is to use cleared versions of
  570. allocators unless all the fields are initialized manually immediately
  571. after allocation.
  572. @node Troubleshooting
  573. @section Troubleshooting the garbage collector
  574. @cindex garbage collector, troubleshooting
  575. With the current garbage collector implementation, most issues should
  576. show up as GCC compilation errors. Some of the most commonly
  577. encountered issues are described below.
  578. @itemize @bullet
  579. @item Gengtype does not produce allocators for a @code{GTY}-marked type.
  580. Gengtype checks if there is at least one possible path from GC roots to
  581. at least one instance of each type before outputting allocators. If
  582. there is no such path, the @code{GTY} markers will be ignored and no
  583. allocators will be output. Solve this by making sure that there exists
  584. at least one such path. If creating it is unfeasible or raises a ``code
  585. smell'', consider if you really must use GC for allocating such type.
  586. @item Link-time errors about undefined @code{gt_ggc_r_foo_bar} and
  587. similarly-named symbols. Check if your @file{foo_bar} source file has
  588. @code{#include "gt-foo_bar.h"} as its very last line.
  589. @end itemize