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

[Daniel Jacobowitz <drow at false dot org>]

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

> Also, when stepping through this program in gdb, we will hop into the
> memcpy inline, which is really uninteresting to the user.  I guess
> for *mmintrin.h users this is the same.

This is just GDB's lack of inlining support.  I plan to contribute
inlining support for GDB later this year (we have it working).  Hiding
artificial functions in the backtrace in our implementation would be
easy.  Hiding them and showing the call site whenever you're inside
them would be harder, but not a lot harder.

> +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?

> Now, if the opposition to __nodebug__ is really so strong, here is
> a patch which tries to implement what has been suggested.
> The attribute is called __artificial__ instead, for Dwarf2/3 will set
> DW_AT_artificial on the abstract DIE (or should it be instead present
> on the inlined instance where we have DW_AT_call_{file,line} attributes?)

Doesn't really matter unless there is also an out of line instance
referencing the same abstract DIE.  Consumers will check whether the
inlined instance is artificial and automatically follow the reference
to the abstract DIE.

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

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

-- 
Daniel Jacobowitz
CodeSourcery