public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Lewis Hyatt <lhyatt@gmail.com>, <gcc-patches@gcc.gnu.org>
Subject: GTY: Explicitly reject 'string_length' option for (fields in) global variables (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)
Date: Wed, 5 Jul 2023 09:50:58 +0200	[thread overview]
Message-ID: <87bkgqvlst.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <aa605ce17fbe4783b46a2cea7b3fa6d99d2cbfe6.1666131048.git.lhyatt@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

Hi!

On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> [...] add a new
> GTY option "string_length" so that gt_pch_note_object can be informed the
> actual length it ought to use, [...]

> --- 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

In preparation for another thing I'm working on, OK to push the attached
"GTY: Explicitly reject 'string_length' option for (fields in) global variables"
(with <https://inbox.sourceware.org/[TODO]> pointing to this message)?


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-GTY-Explicitly-reject-string_length-option-for-field.patch --]
[-- Type: text/x-diff, Size: 4483 bytes --]

From 9130fe7873c2e1b44ab2449bfe022837e26f710c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue, 4 Jul 2023 11:46:50 +0200
Subject: [PATCH] GTY: Explicitly reject 'string_length' option for (fields in)
 global variables

This is preparational for another thing that I'm working on.  No change in
behavior -- other than a more explicit error message.

The 'string_length' option currently is not supported for (fields in) global
variables.  For example, if we apply the following (made-up) changes:

    --- gcc/c-family/c-cppbuiltin.cc
    +++ gcc/c-family/c-cppbuiltin.cc
    @@ -1777 +1777 @@ struct GTY(()) lazy_hex_fp_value_struct
    -  const char *hex_str;
    +  const char * GTY((string_length("strlen(%h.hex_str) + 1"))) hex_str;

    --- gcc/varasm.cc
    +++ gcc/varasm.cc
    @@ -66 +66 @@ along with GCC; see the file COPYING3.  If not see
    -extern GTY(()) const char *first_global_object_name;
    +extern GTY((string_length("strlen(%h.first_global_object_name) + 1"))) const char *first_global_object_name;

..., we get:

    [...]
    build/gengtype  \
                        -S [...]/source-gcc/gcc -I gtyp-input.list -w tmp-gtype.state
    /bin/sh [...]/source-gcc/gcc/../move-if-change tmp-gtype.state gtype.state
    build/gengtype  \
                        -r gtype.state
    [...]/source-gcc/gcc/varasm.cc:66: global `first_global_object_name' has unknown option `string_length'
    [...]/source-gcc/gcc/c-family/c-cppbuiltin.cc:1789: field `hex_str' of global `lazy_hex_fp_values[0]' has unknown option `string_length'
    make[2]: *** [Makefile:2890: s-gtype] Error 1
    [...]

These errors occur when writing "GC roots", where -- per my understanding --
'string_length' isn't relevant for actual GC purposes.  However, like
elsewhere, it is for PCH purposes, and simply accepting 'string_length' here
isn't sufficient: we'll still get '(gt_pointer_walker) &gt_pch_n_S' used in the
'struct ggc_root_tab' instances, and there's no easy way to change that to
instead use 'gt_pch_n_S2' with explicit 'size_t string_len' argument.  (At
least not sufficiently easy to justify spending any further time on, given that
I don't have an actual use for that feature.)

So, until an actual need arises, and/or to avoid the next person looking into
this having to figure out the same thing again, let's just document this
limitation:

    [...]/source-gcc/gcc/varasm.cc:66: option `string_length' not supported for global `first_global_object_name'
    [...]/source-gcc/gcc/c-family/c-cppbuiltin.cc:1789: option `string_length' not supported for field `hex_str' of global `lazy_hex_fp_values[0]'

This amends commit f3b957ea8b9dadfb1ed30f24f463529684b7a36a
"pch: Fix streaming of strings with embedded null bytes".

	gcc/
	* gengtype.cc (write_root, write_roots): Explicitly reject
	'string_length' option.
	* doc/gty.texi (GTY Options) <string_length>: Document.
---
 gcc/doc/gty.texi |  4 ++++
 gcc/gengtype.cc  | 10 ++++++++++
 2 files changed, 14 insertions(+)

diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
index 9fc509128fe..24799aa6781 100644
--- a/gcc/doc/gty.texi
+++ b/gcc/doc/gty.texi
@@ -217,6 +217,10 @@ struct GTY(()) non_terminated_string @{
 @};
 @end smallexample
 
+The @code{string_length} option currently is not supported for (fields
+in) global variables.
+@c <https://inbox.sourceware.org/[TODO]>
+
 @findex skip
 @item skip
 
diff --git a/gcc/gengtype.cc b/gcc/gengtype.cc
index 7763f40e9ab..04dbb0de8bd 100644
--- a/gcc/gengtype.cc
+++ b/gcc/gengtype.cc
@@ -4337,6 +4337,11 @@ write_root (outf_p f, pair_p v, type_p type, const char *name, int has_length,
 	      else if (strcmp (o->name, "desc") == 0
 		       && o->kind == OPTION_STRING)
 		desc = o->info.string;
+	      else if (strcmp (o->name, "string_length") == 0)
+		/* See 'doc/gty.texi'.  */
+		error_at_line (line,
+			       "option `%s' not supported for field `%s' of global `%s'",
+			       o->name, fld->name, name);
 	      else
 		error_at_line (line,
 			       "field `%s' of global `%s' has unknown option `%s'",
@@ -4535,6 +4540,11 @@ write_roots (pair_p variables, bool emit_pch)
 	  deletable_p = 1;
 	else if (strcmp (o->name, "cache") == 0)
 	  ;
+	else if (strcmp (o->name, "string_length") == 0)
+	  /* See 'doc/gty.texi'.  */
+	  error_at_line (&v->line,
+			 "option `%s' not supported for global `%s'",
+			 o->name, v->name);
 	else
 	  error_at_line (&v->line,
 			 "global `%s' has unknown option `%s'",
-- 
2.34.1


  parent reply	other threads:[~2023-07-05  7:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 22:14 [PATCH] pch: Fix streaming of strings with embedded null bytes Lewis Hyatt
2022-10-19 11:54 ` Richard Sandiford
2022-10-19 12:08   ` Jakub Jelinek
2022-10-19 12:17     ` Richard Sandiford
2022-10-19 12:23       ` Jakub Jelinek
2022-10-19 12:47         ` Lewis Hyatt
2023-07-04 15:50 ` 'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes) Thomas Schwinge
2023-07-04 19:56   ` Lewis Hyatt
2023-07-05  7:56     ` GTY: Enhance 'string_length' option documentation (was: 'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)) Thomas Schwinge
2023-07-05  8:15       ` Richard Biener
2023-07-05  7:50 ` Thomas Schwinge [this message]
2023-07-05  8:13   ` GTY: Explicitly reject 'string_length' option for (fields in) global variables (was: [PATCH] pch: Fix streaming of strings with embedded null bytes) Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkgqvlst.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lhyatt@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).