Re: [PATCH] libgccjit: Add option to allow special characters in function names

[Iain Sandoe <idsandoe@googlemail.com>]

> On 20 Feb 2024, at 20:50, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote:
>> Hi.
>> This patch adds a new option to allow special characters like . and $
>> in function names.
>> This is useful to allow for mangling using those characters.
>> Thanks for the review.
> 
> Thanks for the patch.
> 
>> diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
>> index 10a0e50f9f6..4af75ea7418 100644
>> --- a/gcc/jit/docs/topics/contexts.rst
>> +++ b/gcc/jit/docs/topics/contexts.rst
>> @@ -453,6 +453,10 @@ Boolean options
>>      If true, the :type:`gcc_jit_context` will not clean up intermediate files
>>      written to the filesystem, and will display their location on stderr.
>> 
>> +  .. macro:: GCC_JIT_BOOL_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES
>> +
>> +     If true, allow special characters like . and $ in function names.
> 
> The documentation and the comment in libgccjit.h say:
>  "allow special characters like . and $ in function names."
> and on reading the implementation, the special characters are exactly
> '.' and '$'.
> 
> The API seems rather arbitrary and inflexible to me; why the choice of
> those characters?  Presumably those are the ones that Rust's mangling
> scheme uses, but do other mangling schemes require other chars?
> 
> How about an API for setting the valid chars, something like:
> 
> extern void
> gcc_jit_context_set_valid_symbol_chars (gcc_jit_context *ctxt,
>                                        const char *chars);
> 
> to specify the chars that are valid in addition to underscore and
> alphanumeric.
> 
> In your case you'd call:
> 
>  gcc_jit_context_set_valid_symbol_chars (ctxt, ".$");
> 
> Or is that overkill?

If we ever wanted to support objective-c (NeXT runtime) then we’d need to
be able to support +,-,[,] space and : at least.  The interesting thing there is
that most assemblers do not support that either (and the symbols then need
to be quoted into the assembler) .

So, it’s not (IMO) overkill considering at least one potential extension.

Iain

> 
> Dave
>