Re: x86: generate template sets data at build time

Re: x86: generate template sets data at build time

[Alan Modra]

> +    /* Type checks to compensate for the conversion through void * which
> +       occurs during hash table insertion / lookup.  */
> +    (void)(sets == &current_templates->start);
> +    (void)(end == &current_templates->end);

This results in asan complaining about "member access within null
pointer of type 'const templates'".

-- 
Alan Modra
Australia Development Lab, IBM

Re: x86: generate template sets data at build time

[Jan Beulich]

On 14.12.2022 06:14, Alan Modra wrote:
>> +    /* Type checks to compensate for the conversion through void * which
>> +       occurs during hash table insertion / lookup.  */
>> +    (void)(sets == &current_templates->start);
>> +    (void)(end == &current_templates->end);
> 
> This results in asan complaining about "member access within null
> pointer of type 'const templates'".

Interesting. How can it know that current_templates is still NULL?
(I guess one can't expect it to realize that with the cast to void
this doesn't really stand a chance of exhibiting UB; technically
the compiler _may_ generate code for this nevertheless, and that
code _may_ do anything due to it being UB.) It's also not clear to
me what to do to work around the issue: Assign to current_templates
instead, followed by assigning back NULL after the checks? (This
would feel like clutter to me.) Are there other "standard" ways of
working around such border line asan complaints?

Jan

Re: x86: generate template sets data at build time

[Alan Modra]

On Wed, Dec 14, 2022 at 08:40:37AM +0100, Jan Beulich wrote:
> On 14.12.2022 06:14, Alan Modra wrote:
> >> +    /* Type checks to compensate for the conversion through void * which
> >> +       occurs during hash table insertion / lookup.  */
> >> +    (void)(sets == &current_templates->start);
> >> +    (void)(end == &current_templates->end);
> > 
> > This results in asan complaining about "member access within null
> > pointer of type 'const templates'".
> 
> Interesting. How can it know that current_templates is still NULL?

It is instrumented and hits the error at runtime.

> (I guess one can't expect it to realize that with the cast to void
> this doesn't really stand a chance of exhibiting UB; technically
> the compiler _may_ generate code for this nevertheless, and that
> code _may_ do anything due to it being UB.) It's also not clear to
> me what to do to work around the issue: Assign to current_templates
> instead, followed by assigning back NULL after the checks? (This
> would feel like clutter to me.) Are there other "standard" ways of
> working around such border line asan complaints?

Yes, check for NULL before doing the operation.  In this case I'm
inclined to just delete the type checking.

-- 
Alan Modra
Australia Development Lab, IBM

Re: x86: generate template sets data at build time

[Jan Beulich]

On 14.12.2022 09:19, Alan Modra wrote:
> On Wed, Dec 14, 2022 at 08:40:37AM +0100, Jan Beulich wrote:
>> On 14.12.2022 06:14, Alan Modra wrote:
>>>> +    /* Type checks to compensate for the conversion through void * which
>>>> +       occurs during hash table insertion / lookup.  */
>>>> +    (void)(sets == &current_templates->start);
>>>> +    (void)(end == &current_templates->end);
>>>
>>> This results in asan complaining about "member access within null
>>> pointer of type 'const templates'".
>>
>> Interesting. How can it know that current_templates is still NULL?
> 
> It is instrumented and hits the error at runtime.

Oh, I see. (Apologies for my very limited knowledge of asan behavior.)

>> (I guess one can't expect it to realize that with the cast to void
>> this doesn't really stand a chance of exhibiting UB; technically
>> the compiler _may_ generate code for this nevertheless, and that
>> code _may_ do anything due to it being UB.) It's also not clear to
>> me what to do to work around the issue: Assign to current_templates
>> instead, followed by assigning back NULL after the checks? (This
>> would feel like clutter to me.) Are there other "standard" ways of
>> working around such border line asan complaints?
> 
> Yes, check for NULL before doing the operation.  In this case I'm
> inclined to just delete the type checking.

No, I put the checks there specifically, as otherwise nothing will
guarantee that breakage of the underlying assumption will be noticed
at build time already. I'll wrap the checks in a conditional then.

Jan

Re: x86: generate template sets data at build time

[Alan Modra]

On Wed, Dec 14, 2022 at 06:49:52PM +1030, Alan Modra wrote:
> Yes, check for NULL before doing the operation.  In this case I'm
> inclined to just delete the type checking.

Or make an inine wrapper for str_hash_insert and str_hash_find.

-- 
Alan Modra
Australia Development Lab, IBM

Re: x86: generate template sets data at build time

[Andreas Schwab]

On Dez 14 2022, Jan Beulich via Binutils wrote:

> Are there other "standard" ways of working around such border line
> asan complaints?

Put the check in a non-evaluated context, like static_assert.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."