public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* new ubsan handler
@ 2022-12-17 19:35 Martin Uecker
  2022-12-19  8:44 ` Martin Liška
  0 siblings, 1 reply; 5+ messages in thread
From: Martin Uecker @ 2022-12-17 19:35 UTC (permalink / raw)
  To: gcc



Hi all,

what is the process for adding a new UBsan handler?

We have the source in the GCC tree, but I guess this
should go via LLVM?


Martin


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new ubsan handler
  2022-12-17 19:35 new ubsan handler Martin Uecker
@ 2022-12-19  8:44 ` Martin Liška
  2022-12-19  9:25   ` Martin Uecker
  0 siblings, 1 reply; 5+ messages in thread
From: Martin Liška @ 2022-12-19  8:44 UTC (permalink / raw)
  To: Martin Uecker, gcc

On 12/17/22 20:35, Martin Uecker wrote:
> 
> 
> Hi all,
> 
> what is the process for adding a new UBsan handler?

Hello.

Yes, we sync the run-time library from LLVM project. So a new sanitizer
should go there first.

> 
> We have the source in the GCC tree, but I guess this
> should go via LLVM?

And the compiler support (instrumentation) is independent.

Cheers,
Martin

> 
> 
> Martin
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new ubsan handler
  2022-12-19  8:44 ` Martin Liška
@ 2022-12-19  9:25   ` Martin Uecker
  2022-12-19 14:22     ` Martin Liška
  0 siblings, 1 reply; 5+ messages in thread
From: Martin Uecker @ 2022-12-19  9:25 UTC (permalink / raw)
  To: Martin Liška, gcc

Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:
> On 12/17/22 20:35, Martin Uecker wrote:
> > 
> > 
> > Hi all,
> > 
> > what is the process for adding a new UBsan handler?
> 
> Hello.
> 
> Yes, we sync the run-time library from LLVM project. So a new
> sanitizer
> should go there first.
> 
> > 
> > We have the source in the GCC tree, but I guess this
> > should go via LLVM?
> 
> And the compiler support (instrumentation) is independent.

Thanks Martin!

Does it make sense to send the full patch (with changes
to the compiler and library) to gcc-patches first for
review?

I am working on a patch that calls a handler when bounds
for VM-types do not match on assignment.


Martin


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new ubsan handler
  2022-12-19  9:25   ` Martin Uecker
@ 2022-12-19 14:22     ` Martin Liška
  2022-12-19 15:43       ` Martin Uecker
  0 siblings, 1 reply; 5+ messages in thread
From: Martin Liška @ 2022-12-19 14:22 UTC (permalink / raw)
  To: Martin Uecker, gcc

On 12/19/22 10:25, Martin Uecker wrote:
> Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:
>> On 12/17/22 20:35, Martin Uecker wrote:
>>>
>>>
>>> Hi all,
>>>
>>> what is the process for adding a new UBsan handler?
>>
>> Hello.
>>
>> Yes, we sync the run-time library from LLVM project. So a new
>> sanitizer
>> should go there first.
>>
>>>
>>> We have the source in the GCC tree, but I guess this
>>> should go via LLVM?
>>
>> And the compiler support (instrumentation) is independent.
> 
> Thanks Martin!
> 
> Does it make sense to send the full patch (with changes
> to the compiler and library) to gcc-patches first for
> review?

Yep, please CC me.

> 
> I am working on a patch that calls a handler when bounds
> for VM-types do not match on assignment.

Nice. So basically something like -fsanitize=bounds/bounds-strict/object-size ?

Martin

> 
> 
> Martin
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: new ubsan handler
  2022-12-19 14:22     ` Martin Liška
@ 2022-12-19 15:43       ` Martin Uecker
  0 siblings, 0 replies; 5+ messages in thread
From: Martin Uecker @ 2022-12-19 15:43 UTC (permalink / raw)
  To: Martin Liška, gcc

Am Montag, dem 19.12.2022 um 15:22 +0100 schrieb Martin Liška:
> On 12/19/22 10:25, Martin Uecker wrote:
> > Am Montag, dem 19.12.2022 um 09:44 +0100 schrieb Martin Liška:
> > > On 12/17/22 20:35, Martin Uecker wrote:
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > what is the process for adding a new UBsan handler?
> > > 
> > > Hello.
> > > 
> > > Yes, we sync the run-time library from LLVM project. So a new
> > > sanitizer
> > > should go there first.
> > > 
> > > > 
> > > > We have the source in the GCC tree, but I guess this
> > > > should go via LLVM?
> > > 
> > > And the compiler support (instrumentation) is independent.
> > 
> > Thanks Martin!
> > 
> > Does it make sense to send the full patch (with changes
> > to the compiler and library) to gcc-patches first for
> > review?
> 
> Yep, please CC me.
> 
> > 
> > I am working on a patch that calls a handler when bounds
> > for VM-types do not match on assignment.
> 
> Nice. So basically something like -fsanitize=bounds/bounds-
> strict/object-size ?

Yes, it would diagnose the following mismatch
and other similar cases:

int a[10];
int n = 5;
char (*p)[n] = &a;


Martin











^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-12-19 15:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-17 19:35 new ubsan handler Martin Uecker
2022-12-19  8:44 ` Martin Liška
2022-12-19  9:25   ` Martin Uecker
2022-12-19 14:22     ` Martin Liška
2022-12-19 15:43       ` Martin Uecker

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