On 13 Nov 2006 16:16:50 -0000, acme at mandriva dot com
<[EMAIL PROTECTED]> wrote:
------- Comment #8 from acme at mandriva dot com 2006-11-13 16:16 -------
> > OK, I thought that this was due to something like what you described, even
not
> > knowing that much about gcc internals, but I thought that even in this case
the
> > DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow
me to
> > do what I want with my tools :-\
>
> There is nothing to emit debug info about, so we don't.
>
Well, at least gcc emits this:
<1><a2f2>: Abbrev Number: 65 (DW_TAG_subprogram)
DW_AT_sibling : <a324>
DW_AT_name : (indirect string, offset: 0x4515): __task_rq_lock
DW_AT_decl_file : 1
DW_AT_decl_line : 378
DW_AT_prototyped : 1
DW_AT_type : <9a2f>
DW_AT_inline : 3 (declared as inline and inlined)
But no DW_TAG_inlined_subroutine, as we've been discussing:
[EMAIL PROTECTED] net-2.6.20]$ readelf -wi
../OUTPUT/qemu/net-2.6.20/kernel/sched.o
| grep a2f2
DW_AT_sibling : <a2f2>
<1><a2f2>: Abbrev Number: 65 (DW_TAG_subprogram)
[EMAIL PROTECTED] net-2.6.20]$
I'm quite aware of what GCC outputs here :)
However, past the initial declarations, we don't output debug
information about what the state of the IR is at random points in the
compilation, only about what the final output looks like. Since there
is no inlined code left, we don't end up saying there is an inlined
subroutine.
Even if we could change this, i'm not sure we'd want to. It doesn't
seem incorrect at all to do what we do.
Otherwise, you'd end up with inlined subroutine dies with no low
pc/high pc associated with them, which seems nonsensical.
