search for: unmangling

Hi, I am looking for a way to get unmangled subprogram names from a DWARFContext. The name I want is available in the attribute `DW_AT_name` [1], but as far as I can tell this is only returned as a fallback in `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name is not available [2]. If this is not currently possible, is there any interest in adding such access to the public

That doesn't seem possible with the public API or am I mistaking? On Wed, May 7, 2014 at 12:13 AM, Eric Christopher <echristo at gmail.com>wrote: > On Tue, May 6, 2014 at 8:09 PM, Isaiah Norton <isaiah.norton at gmail.com> > wrote: > > Hi, > > > > I am looking for a way to get unmangled subprogram names from a > > DWARFContext. The name I want is

The use case is getting the short name for backtraces. There are other options, but I figured it was worth a shot trying to access from the DWARF structure because what we need is already stored there anyway. Thanks, Isaiah On Wed, May 7, 2014 at 12:24 PM, Alexey Samsonov <samsonov at google.com>wrote: > Yeah, public API of DebugInfo library is quite minimalistic. But I agree >

On Wed, May 7, 2014 at 11:33 AM, Eric Christopher <echristo at gmail.com>wrote: > Have you checked out llvm-symbolize? It's what the asan folk > (including Alexey) have created for backtrace symbolication. > Yeah, we potentially can add some kind of option: "llvm-symbolizer -print-short-function-names", I don't yet see why this would be valuable. What's wrong

On Wed, May 7, 2014 at 11:38 AM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The use case for this is in Julia backtraces. We don't have a consistent > way to mangle the function names for linkage (we might at some point in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access

...nding of the > name without having to parse C++ decls. > Somewhat off the cuff, but I think it would be nice if commandline object inspection tools could query for a particular symbol when the user specified it in the C++, unmangled form. Generally, it seems useful to unify the mangling and unmangling code if only so that we constantly round-trip test both halves and don't end up with divergences. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120705/aee853a5/attachment.html>

When having a project that's partially bitcode and partially native code, should lld allow linking a native .o to a bitcode .o? specifically in my case, I've got an stdcall function in bitcode, called by native code, but it can't find the symbol (bitcode has it unmangled, native code with _ and @20)

On Jul 5, 2012, at 1:08 AM, Chandler Carruth <chandlerc at google.com> wrote: > In the same way that the core LLVM libraries have support routines for DWARF, I think that both mangling and demangling should be provided as well. How would LLVM provide support for mangling? And what tools actually need it? I also wonder if we need more from a demangler than just a string. I know linker

On Mon, Mar 02, 2015 at 12:12:34AM -0500, John Criswell wrote: > On 3/2/15 12:07 AM, Haopeng Liu wrote: > >Got it, thanks. But in my pass, I use function name to locate. Can I > >disable mangling in clang? > > No, but you can probably fine a library that can either mangle the original > name or demangle the name you're seeing in the LLVM bitcode. > > As an FYI,

Howdy, I'm working with some external code written in C++, which I would like to call via dyn.load() and .C() from R. The function prototype looks like: gaRemin(int *, float *, float *, int *, float *, float *, float *, float *, float *) but to call this function from R using .C() I have had to use the mangled version of this

Mixing native and bitcode files should just work, and that happens all the time, as most programs need at least crt.o (which is a precompiled native object file containing startup code). Could you elaborate the issue a bit? It might be a bug in lld. On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 30, 2018, at 11:23, Carlo Kok

The problem is a bitcode implementation that has a stdcall function that's used from native code. 1 side has _elements_exception_handler, compiled that would be __elements_exception_handler at 20 due to stdcall. The native bit has the mangled name and the linker can't find it as the bitcode indexes have it without mangling. I'll try to prepare a testcase when I get back in the office.

The short version: When I port our application from LLVM 7 to 8, some JIT-compiled code seems to break the implicit instanciation of C++ templates. That is, when I try to resolve a symbol defined by the code, I get undefined symbols corresponding to methods that are actually function templates. If the code adds explicit template instanciations, the problem goes away. Does anybody have an

On Fri, Mar 30, 2018, at 11:23, Carlo Kok via llvm-dev wrote: > When having a project that's partially bitcode and partially native code, should lld allow linking a native .o to a bitcode .o? > > specifically in my case, I've got an stdcall function in bitcode, called by native code, but it can't find the symbol (bitcode has it > unmangled, native code with _ and @20)

We have built a tool which will take in a CDFG (in a particular format) and do some design automation based on it. The effort is to extend this tool to take an input from in the form of a systemC (extension of C++) code. The IR was used to generate the CDFG of the source code. But the requirement is to generate the CDFG of only a specific function and hence I am looking to iterate over the member

Hi all, Finally I managed to find out a strange problem under Visual C During the link of the HowToUseJIT program, I was always missing some symbols... and I was going crazy testing out different options... At the end, unmangling the differences in what linker was searching and what was present in the libraries, I found that the problem is that we have something like this... Value.h struct Value { bla bla bla } and around in the other files: SlotCalculator.h SchedGraph.h <big snip> class Value; The linker compla...

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

Sorry yes, peter is the unmangled user name. On Fri, Nov 4, 2016 at 2:18 AM, Steffen Kaiser < skdovecot at smail.inf.fh-brs.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 3 Nov 2016, Peter Fraser wrote: > > The command doveadm user -u username successfully returns the username and >> any information it can for the user in AD. As a matter of

Clang may be avoiding this problem because it will always emit "\01__elements_exception_handler at 20" as the function name. It probably does that for precisely this reason. On Fri, Mar 30, 2018 at 11:55 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The problem is a bitcode implementation that has a stdcall function that's > used from native code. 1

You can add symbols from Archieve via StaticLibrarySearchGenerator. But it is added recently though On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > I tried it, but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; >