[PATCH] Fix for debug info for thunks using mangled name (PR14569)

[David Blaikie]

On Aug 22, 2013 1:21 AM, "DINESH KUMAR DWIVEDI" <dinesh.d at samsung.com>
wrote:
>
> Hi All,
>
> I was looking in to PR14569 [http://llvm.org/bugs/show_bug.cgi?id=14569]
and here are my findings.
>
> GDB uses following attributes while printing function names, in order.
>      1. Linkage Name, if available, gdb demangles it and use it to print
function name.
>      2. Name, if available, gdb uses it as it is without demangling it.
>      3. GDB tries to generage name of the function with other information
available.
>
> In case of clang, for compiler generated functions, [where HasDecl() is
false], only Name attribute is being set in debug info.
>
> So to fix bug on clang, we can do following.
>
> 1. Do not set both name and linkage_name attributes of just set
linkage_name attribute. This makes testcase [gdb.cp/virtfunc.cpp] to pass
but causes failures in 2 CodeGenCXX tests [debug-info-global-ctor-dtor.cpp
and debug-info-thunk.cpp] which expect name attribute with mangled name of
the function. I am also not sure, if other tools also depends on name
attributes with mangled anme for compiler generated function.

I assume these two CodeGenCXx test cases are just a matter of history and
could probably be changed if we decide that linkage name is the right name
to use and to drop the plain name entirely. Existing tests don't always
represent the immutable truth of required behavior.

>
> 2. Set both name and linkage_name attributes. This makes testcase
[gdb.cp/virtfunc.cpp] to pass and does not have any side effect on existing
clang/ llvm tests. But this will increase debug info size. I suggest to
enable this fix if Full Debug Info option is enabled.

I think we already have some size concerns regarding emitting debug info
for these thunks, so I'll ask the standard question:

What does GCC (top of trees or latest release) do here? Both names?
Neither? Just linkage?

>
> I have attached patch using second approach. Please let me know if this
is fine.
>
> Regards
> Dinesh Dwivedi
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130822/6fdf8b3c/attachment.html>