[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction

[David Blaikie]

On Wed, Apr 10, 2013 at 4:48 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Eric,
>
> On 10/04/13 00:20, Eric Christopher wrote:
>>
>> On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote:
>>>
>>> Hi David, I'm seeing an assertion failure when passing this node
>>>
>>>    !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t",
>>> i32
>>> 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ]
>>> [fn_t] [line 5, size 0, align 0, offset 0] [from ]
>>>
>>> as the function type parameter to DIBuilder::createFunction, due to this
>>> check
>>> in DebugInfo.cpp:
>>>
>>> 486       DICompositeType Ty = getType();
>>> 487       if (!Ty.Verify())
>>> 488         return false;
>>>
>>> Is it in fact wrong to pass a typedef here?
>>>
>>
>> I can't come up with a way that'd be correct, no. You should be using
>> createSubroutineType and passing that into the builder. Have example
>> code where this is coming up?
>
>
> OK, it looks like a DW_TAG_typedef node defines a new type.  If the original
> type is a subroutine type, I don't see why a typedef of it shouldn't be used
> anywhere the original could.  After all, it is just an alternative name for
> the same thing.  You clearly have a different mental model of what a typedef
> is, but what is it?

I think you might be ascribing more rigor to the debug info IR than is
due. It's a fairly pragmatic implementation without much thought (so
far as I can tell) to high level principles of types, etc. It's
essentially "how do we describe the stuff we need to produce debug
info".

If the function's type just needs to be a type, then that's all it is
(a function type) & all that's supported by the backend most likely -
there's no particular merit in providing the possibility for that type
to be indirected through a typedef or anything of the sort.

If there's any case where we actually produce different/inferior debug
info because of this representation, then that's a bug worth
considering that might necessitate a change in the IR representation
to allow a function's type to be a typedef.

eg: I wonder what this looks like in GCC debug info, Clang debug info,
and what is correct/good:

typedef int foo(int);
foo bar;

is 'bar' a function of type "int(int)" or a function of type "foo"
which is a typedef of type "int(int)". I suppose it could be the
latter, in which case we should be usincg/allowing a function's type
to be a typedef.