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

[Eric Christopher]

On Mon, Apr 15, 2013 at 6:20 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 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.

It's not going to come up with anything since bar is unused :)

I've been unable to come up with any way to use foo as a type for a
function. If you can come up with one...

-eric