This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] PR 12389
On Sun, 19 Oct 2003 10:23:24 +0200, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Sun, 19 Oct 2003 10:00:39 +0200, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Also what about COMDAT functions? I guess the debug info should be
>> > conservative then and always claim that function has been inlined as it
>> > may be inlined in the other compilation unit, right?
>>
>> I don't see what COMDAT has to do with this. If the function is inlined in
>> another translation unit, it will have debug info there.
>
> So the debug info above is generated for each inline copy of the given
> function separately? How we can end up with DW_INL_declared_not_inlined
> then?
If a function is declared inline but not actually inlined, we may still
separate it into abstract and inline instances, in which case we would use
DW_INL_declared_not_inlined. This is useful for -feliminate-dwarf2-dups,
which relies on the debug info for a particular header being identical in
different translation units.
> In the case it is generated just once, I would expect commonized
> functions after linking to also commonize the debug info so it should be
> conservative?
When we use section groups, we can discard the debug info for a function
along with the function itself. But in the case of an inline function,
this only applies to the concrete instance; we will still have a separate
abstract instance.
Jason