diff options
author | Lewis Hyatt <lhyatt@gmail.com> | 2022-10-14 13:52:12 -0400 |
---|---|---|
committer | Lewis Hyatt <lhyatt@gmail.com> | 2022-10-19 09:26:09 -0400 |
commit | f3b957ea8b9dadfb1ed30f24f463529684b7a36a (patch) | |
tree | 3834aa6c8ae665d37326b8e06543cb77cd9a9524 /gcc/doc | |
parent | 09fed44cabd50f3d8e050f91cc2db02364ce9176 (diff) | |
download | gcc-f3b957ea8b9dadfb1ed30f24f463529684b7a36a.zip gcc-f3b957ea8b9dadfb1ed30f24f463529684b7a36a.tar.gz gcc-f3b957ea8b9dadfb1ed30f24f463529684b7a36a.tar.bz2 |
pch: Fix streaming of strings with embedded null bytes
When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
(whether they live in GC-controlled memory or not) will be marked for PCH
output by the routine gt_pch_note_object in ggc-common.cc. This routine
special-cases plain char* strings, and in particular it uses strlen() to get
their length. Thus it does not handle strings with embedded null bytes, but it
is possible for something PCH cares about (such as a string literal token in a
macro definition) to contain such embedded nulls. To fix that up, add a new
GTY option "string_length" so that gt_pch_note_object can be informed the
actual length it ought to use, and use it in the relevant libcpp structs
(cpp_string and ht_identifier) accordingly.
gcc/ChangeLog:
* gengtype.cc (output_escaped_param): Add missing const.
(get_string_option): Add missing check for option type.
(walk_type): Support new "string_length" GTY option.
(write_types_process_field): Likewise.
* ggc-common.cc (gt_pch_note_object): Add optional length argument.
* ggc.h (gt_pch_note_object): Adjust prototype for new argument.
(gt_pch_n_S2): Declare...
* stringpool.cc (gt_pch_n_S2): ...new function.
* doc/gty.texi: Document new GTY((string_length)) option.
libcpp/ChangeLog:
* include/cpplib.h (struct cpp_string): Use new "string_length" GTY.
* include/symtab.h (struct ht_identifier): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/pch/pch-string-nulls.C: New test.
* g++.dg/pch/pch-string-nulls.Hs: New test.
Diffstat (limited to 'gcc/doc')
-rw-r--r-- | gcc/doc/gty.texi | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi index 81aafd1..4f791b3 100644 --- a/gcc/doc/gty.texi +++ b/gcc/doc/gty.texi @@ -196,7 +196,26 @@ static GTY((length("reg_known_value_size"))) rtx *reg_known_value; Note that the @code{length} option is only meant for use with arrays of non-atomic objects, that is, objects that contain pointers pointing to other GTY-managed objects. For other GC-allocated arrays and strings -you should use @code{atomic}. +you should use @code{atomic} or @code{string_length}. + +@findex string_length +@item string_length ("@var{expression}") + +In order to simplify production of PCH, a structure member that is a plain +array of bytes (an optionally @code{const} and/or @code{unsigned} @code{char +*}) is treated specially by the infrastructure. Even if such an array has not +been allocated in GC-controlled memory, it will still be written properly into +a PCH. The machinery responsible for this needs to know the length of the +data; by default, the length is determined by calling @code{strlen} on the +pointer. The @code{string_length} option specifies an alternate way to +determine the length, such as by inspecting another struct member: + +@smallexample +struct GTY(()) non_terminated_string @{ + size_t sz; + const char * GTY((string_length ("%h.sz"))) data; +@}; +@end smallexample @findex skip @item skip |