llvm dev - Dec 2014 - [LLVMdev] How to get the original function name in C++?

Hi, everyone!
    I'm new here trapped by a simple problem for days.
    When LLVM translates C++ source code to IR, it will add a prefix to the
function name. For example:
source code:
int foo(){
return 1;
}
IR form:
define i32 @_Z3foov() #0 {
entry:
  ret i32 1, !dbg !20
}
    The getName() method returns _Z3foov, then how can I get foo? I know
the debugging information is contained in metadata, but I've no idea on
using it.
    Thanks a lot for any help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/46c216b4/attachment.html>

This is called name mangling, and what you want is a demangler. c++filt is a 
program that does this.

If you're looking for a library function you can call that will do this for
you,
there's __cxa_demangle 
https://mentorembedded.github.io/cxx-abi/abi.html#demangler which should be 
provided by your c++ abi library. Clang might have a more convenient wrapper 
around that or it's own separate implementation, but I'm not sure where
that
would be.


Cheers,

Jon

On 12/11/14 4:52 AM, zy jj wrote:
> Hi, everyone!
>      I'm new here trapped by a simple problem for days.
>      When LLVM translates C++ source code to IR, it will add a prefix to
the
> function name. For example:
> source code:
> int foo(){
> return 1;
> }
> IR form:
> define i32 @_Z3foov() #0 {
> entry:
>    ret i32 1, !dbg !20
> }
>      The getName() method returns _Z3foov, then how can I get foo? I know
> the debugging information is contained in metadata, but I've no idea on
> using it.
>      Thanks a lot for any help.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On 12/11/2014 5:52 AM, zy jj wrote:
> Hi, everyone!
>      I'm new here trapped by a simple problem for days.
>      When LLVM translates C++ source code to IR, it will add a prefix to
> the function name. For example:
> source code:
> int foo(){
> return 1;
> }
> IR form:
> define i32 @_Z3foov() #0 {
> entry:
>    ret i32 1, !dbg !20
> }
>      The getName() method returns _Z3foov, then how can I get foo? I
> know the debugging information is contained in metadata, but I've no
> idea on using it.
>      Thanks a lot for any help.
>
In C++ names are "mangled" when translated to machine instructions. 
This allows for function overloading and such.

Are you looking for something you can call inside of llvm to get the 
demangled name?  At the command line you can use C++flit to get the 
demangled name.  For example:

~$ c++filt _Z3foov
foo()

-- 

-Bill Seurer

When a C++ compiler translates source code it will perform name mangling 
to avoid name collisions due to type overloading.  You can use a tool 
like c++filt to de-mangle the generated names

Cheers,
  Roel

On 11/12/14 11:52, zy jj wrote:
> Hi, everyone!
>      I'm new here trapped by a simple problem for days.
>      When LLVM translates C++ source code to IR, it will add a prefix to
> the function name. For example:
> source code:
> int foo(){
> return 1;
> }
> IR form:
> define i32 @_Z3foov() #0 {
> entry:
>    ret i32 1, !dbg !20
> }
>      The getName() method returns _Z3foov, then how can I get foo? I
> know the debugging information is contained in metadata, but I've no
> idea on using it.
>      Thanks a lot for any help.
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

If you want to get the original name by a library function, as Jonathan
mentioned, you can call __cxa_demangle in cxxabi.h. However, this API is
only available in gcc. If you want something more portable, try glog or
libibert, notice libibert is GPL licensed.

On Thu, Dec 11, 2014 at 7:57 AM, Roel Jordans <r.jordans at tue.nl> wrote:
> When a C++ compiler translates source code it will perform name mangling
> to avoid name collisions due to type overloading.  You can use a tool like
> c++filt to de-mangle the generated names
>
> Cheers,
>  Roel
>
>
> On 11/12/14 11:52, zy jj wrote:
>
>> Hi, everyone!
>>      I'm new here trapped by a simple problem for days.
>>      When LLVM translates C++ source code to IR, it will add a prefix
to
>> the function name. For example:
>> source code:
>> int foo(){
>> return 1;
>> }
>> IR form:
>> define i32 @_Z3foov() #0 {
>> entry:
>>    ret i32 1, !dbg !20
>> }
>>      The getName() method returns _Z3foov, then how can I get foo? I
>> know the debugging information is contained in metadata, but I've
no
>> idea on using it.
>>      Thanks a lot for any help.
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
- Welson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/5db3d7de/attachment.html>

zy jj wrote:
> Hi, everyone!
>      I'm new here trapped by a simple problem for days.
>      When LLVM translates C++ source code to IR, it will add a prefix to
> the function name. For example:
> source code:
> int foo(){
> return 1;
> }
> IR form:
> define i32 @_Z3foov() #0 {
> entry:
>    ret i32 1, !dbg !20
> }
>      The getName() method returns _Z3foov, then how can I get foo? I
> know the debugging information is contained in metadata, but I've no
> idea on using it.
>      Thanks a lot for any help.
You got a few answers about name mangling, but you also asked about 
debug info. If you want to find the original name through debug info 
instead of demangling the mangled name, the relevant subset of debug 
info works like this.

!llvm.dbg.cu = !{!0}

"CU" is short for "compilation unit", the DWARF[1] term for
what C and
C++ call a translation unit, a single .c/.cc file with all its includes. 
The only CU in this .ll file is !0.

!0 = metadata !{metadata !"0x11\004\00clang version 3.6.0 (trunk 
223918)\000\00\000\00\001", metadata !1, metadata !2, metadata !2, 
metadata !3, metadata !2, metadata !2} ; [ DW_TAG_compile_unit ] 
[/home/nicholas/zyjj.cc] [DW_LANG_C_plus_plus]

On the one hand our debug info format is free to change, but on the 
other hand it closely follows the DWARF spec. You can construct an 
llvm::DICompileUnit and pass the the MDNode* for !0, then query its 
getSubprograms() method to find what DWARF calls "subprograms" or what
C/C++ call "functions". It returns a DIArray. For reference, the 
subprograms field is field 3 (zero-indexed) of the compile_unit, so it's 
"metadata !3".

!3 = metadata !{metadata !4}

Our array of subprograms, with one subprogram. Note that this need not 
include all subprograms; methods may only be listed in the 
DW_TAG_class_type for example.

!4 = metadata !{metadata 
!"0x2e\00foo\00foo\00_Z3foov\001\000\001\000\000\00256\000\001", 
metadata !1, metadata !5, metadata !6, null, i32 ()* @_Z3foov, null, 
null, metadata !2} ; [ DW_TAG_subprogram ] [line 1] [def] [foo]

You can construct a DISubprogram with this, and a DISubprogram has a few 
kinds of names. It has a "linkage name" which is the name that you
need
to know in order to link against it, aka. the mangled name. The other 
two names are called "name" and "display name". DWARF does
define what a
name should be, "a string representing the name as it appears in the 
source program" and goes on to clarify that it should be the unmangled 
form. Get it by calling DISubprogram::getName().

However, nowhere does DWARF define what a "display name" is. Taking a 
quick look through clang, I can't see where we ever set it differently 
from "name". If anyone else knows this, please let me know.

Nick

[1] - http://dwarfstd.org/Dwarf4Std.php