Re: [RFC PATCH] Add __attribute__((__artificial__)) (__nodebug__ alternative)

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Aug 31, 2007 at 03:25:12PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 31, 2007 at 03:05:20PM -0400, Jakub Jelinek wrote:
> > Currently, the above will generate compile time warning about buffer
> > overflow in a wrong spot:
> > nn.c: In function 'foo':
> > nn.c:12: warning: call to __builtin___memcpy_chk will always overflow destination buffer
> > While the function name is right, the file and line number points into
> > the glibc headers, so doesn't help much location the error.
> 
> Would this be better?
> 
> nn.c: In function 'memcpy':
> nn.c:12: warning: call to __builtin___memcpy_chk will always overflow destination buffer
> nn.c:18: note: inlined from here

I guess I could live with that...

> > +This attribute is useful for small inline wrappers which if possible
> > +should appear during debugging as a unit, depending on the debug
> > +info format it will either mean marking the function as artificial
> > +or using the caller location for all instructions within the inlined
> > +body.
> 
> I think there's a missing "not" on the second line.  What does "as a
> unit" mean?

I'm open to suggestions.  As a unit means that the whole inline appears
as it it was just one statement or something like that.

> If an out of line instance is going to point at the same DIE you'll
> have a problem though.

Ok, guess I'll stick it alongside of DW_AT_call_{file,line} then.

> > Can gdb, frysk, systemtap and other consumers do something useful with it
> > though (and by default if possible), for backtraces, etc.?
> 
> Is this really right?  Suppose you're looking at a backtrace for
> printf with some arguments, and those arguments seem wrong.  If you go
> up the stack to the inlined function to see where they came from,
> and reach the call site of the inlined function, there'll be a
> strange mismatch...

It is right and desirable.  If there is no overflow, the whole inline
will either just call real memcpy, or expand it inline.  Without
__artificial__ all the instructions (either those that initialize arguments
and the call insn or the target specific memcpy code) are accounted
to the inline, but it is really doing memcpy operation the user is
interested in.  If it needs to do runtime checking, it will
actually call __memcpy_chk instead of memcpy, still there is nothing
of interest to the user about this implementation detail.

	Jakub