On 8/4/25 13:17, Joseph Myers wrote:
> On Mon, 4 Aug 2025, David Faust wrote:
>
>> Hi Joseph,
>>
>> Could you please take a look at the front-end portion of this
>> series when you have a moment?
>>
>> New attributes/handlers - Patch 1:
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690142.html
>
> It looks like the front-end code would accept wide strings (wchar_t,
> char16_t, char32_t), but the code actually processing the tags in
> dwarf2out.c expects narrow strings only.
Thank you for catching this.
The DWARF encoding is using DW_AT_const_value with the 'string'
attribute class, which is defined as "a null-terminated sequence
of zero or more (non-null bytes)". BTF string encoding is similar.
So IMO the best option will be to reject wide strings in the attribute
handler. (The alternative, I guess, is to ensure the argument is
always exported to UTF-8 before being written (?))
I see that we can get the character size from the TREE_TYPE of the
STRING_CST node. Am I correct in thinking that it will be sufficient
to reject any string argument using characters larger than 8 bits?
Something like:
/* Check for and reject wide strings. */
tree arg_chartype = TREE_TYPE (TREE_TYPE (TREE_VALUE (args)));
if (tree_to_uhwi (TYPE_SIZE (arg_chartype)) > 8)
{
error ("unsupported argument string type in %qE attribute", name);
*no_add_attrs = true;
}
>
>> Docs - Patch 5:
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690147.html
>
>> +int * __attribute__ ((btf_type_tag ("__user"))) foo;
>> +@end smallexample
>> +
>> +@noindent
>> +when compiled with @code{-gbtf} results in an additional
>> +@code{BTF_KIND_TYPE_TAG} BTF record to be emitted in the BTF info,
>> +associating the string ``__user'' with the normal @code{BTF_KIND_PTR}
>
> Command-line option names should be marked up with @option{}. It seems
> __user is literal source code text, so @samp{__user} is more appropriate
> than ``__user''.
>
Thanks, I've gone through the docs patch to fix these.
