[llvm-dev] Function name

[via llvm-dev]

Thanks for the correction, it didn't feel like quite the right example and I should have double-checked.
So the original confusion is just based on how llvm-dwarfdump prints things, not on where the name actually lives.
Thanks,
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Saturday, October 27, 2018 2:55 PM
To: Robinson, Paul
Cc: jiangmuhui at gmail.com; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Function name


On Fri, Oct 26, 2018 at 8:28 AM via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi Muhui,

I believe the names in the callgraph are the "mangled" name, which DWARF refers to as the linkage name.  This would be recorded in the DW_AT_MIPS_linkage_name or DW_AT_linkage_name attribute, depending on the version of DWARF.

DW_AT_specification is a way to associate two DWARF entries for the same entity.  You will see this most commonly for inlined functions, where the DWARF entry for the inlined instance has a DW_AT_specification pointing to the "abstract" instance for the same function.

Minor thing: DW_AT_specification is used for decl/def separations rather than inline/concrete/abstract (that uses abstract_origin). But similar stuff, for sure.

  This is intended as a space-saving tactic, as many of the attributes for a function (including its linkage name) are the same across all inlined instances.  The abstract instance has the common attributes, while the concrete instances have the attributes specific to each inlined instance (e.g., code ranges).

As for the PLT segment, I suspect that DWARF does not describe these because they are artifacts of the ABI and do not reflect anything in the source.  The callgraph describes them because they are explicit in the IR.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Muhui Jiang via llvm-dev
Sent: Thursday, October 25, 2018 4:16 PM
To: llvm-dev
Subject: [llvm-dev] Function name

Hi

I refer to the binary generated by C++ code.

I am curious about the name inside the callgraph, which is generated by the tool

opt -dot-callgraph target.bc

I found the names inside the callgraph follow the C++ function name rule. Then I would like to check the name inside the debugging information, which is generated by the command

llvm-dwarfdump -debug-info target.o

I manually checked it, I found sometimes the name(label in the callgraph) is the attribute of `DW_AT_specification`, sometimes is `DW_AT_MIPS_linkage_name`. Can anyone explain these? What should be the right function name inside the dwarf debugging information?

Yeah, llvm-dwarfdump prints the mangled/linkage name next to DW_AT_specification for ease of reading, but in reality the specification doesn't have the linkage name (it's pulling it from the DIE the specification refers to) - use '-v' with llvm-dwarfdump to see the details of how that's all wired up.


Another question is about the PLT segment. I found that the callgraph will contain the functions inside the ELF PLT segment while the dwarf debugging information does not contain them. Could anyone explain these? Many Thanks

Regards
Muhui
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181029/aa9fce90/attachment.html>