aboutsummaryrefslogtreecommitdiff
path: root/gcc/doc
diff options
context:
space:
mode:
authorLewis Hyatt <lhyatt@gmail.com>2022-10-14 13:52:12 -0400
committerLewis Hyatt <lhyatt@gmail.com>2022-10-19 09:26:09 -0400
commitf3b957ea8b9dadfb1ed30f24f463529684b7a36a (patch)
tree3834aa6c8ae665d37326b8e06543cb77cd9a9524 /gcc/doc
parent09fed44cabd50f3d8e050f91cc2db02364ce9176 (diff)
downloadgcc-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.texi21
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