similar to: [LLVMdev] Why do we mangle names in llvm?

I don't remember anything other that what I've written in the bug João has mentioned. Probably something like this patch http://llvm.org/bugs/show_bug.cgi?id=14410#c6 ? 2013/2/20 João Matos <ripzonetriton at gmail.com>: > I think so. There have been other reports lately related to this being > wrong. > > http://llvm.org/bugs/show_bug.cgi?id=14410 > > CC'ing

On Fri, Nov 25, 2011 at 1:47 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Nov 25, 2011, at 2:22 PM, bigcheesegs at gmail.com wrote: > >> In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. > Huh. It only seems to happen with a Windows triple or a Linux triple. Doesn't happen with a Mac triple,

On Nov 25, 2011, at 2:22 PM, bigcheesegs at gmail.com wrote: > In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. Huh. It only seems to happen with a Windows triple or a Linux triple. Doesn't happen with a Mac triple, though--probably because the Darwin assembler supports quoted symbols (i.e. you can enclose an identifier in

Looks to me like it converted the ? into the ascii hexadecimal representation _3F_. I don't think another underscore was pre-pended. This is probably thanks to lib/Target/Mangler.cpp. You'll want to let ? be treated as an acceptable character. static bool isAcceptableChar(char C, bool AllowPeriod) { if ((C < 'a' || C > 'z') && (C < 'A'

On Nov 25, 2011, at 8:39 AM, Michael Spencer wrote: > So I was taking a look at Microsoft C++ ABI support while on vacation, > and ran into a major issue. Given the following llvm-ir: > > $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft > ; ModuleID = 'mangling.cpp' > target datalayout = >

2013/2/21 Anton Korobeynikov <anton at korobeynikov.info>: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. I think clang already adds \01 to __stdcall names, so only the LLVM change is remaining. > I do not think that moving whole mangling to clang is a good idea, >

I needed to be able to update stub pointers for hot functions that get recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do this I added a method that allows pointers to be updated but does not expose any of the other internals of the COD layer. Does anyone have a cleaner way to do this? Has something to facilitate this already been added? Would it be possible to merge this

In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. Sent from my iPhone On Nov 25, 2011, at 2:15 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Nov 25, 2011, at 8:39 AM, Michael Spencer wrote: > >> So I was taking a look at Microsoft C++ ABI support while on vacation, >> and ran into a major

+Lang Hames <lhames at gmail.com>, Master Regent of the Three <No, Two sir> JITs On Thu, Jul 28, 2016 at 12:31 PM Sean Ogden via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I needed to be able to update stub pointers for hot functions that get > recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do > this I added a method that allows pointers to

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return

Hi Sean, This is great, but it couples LogicalDylib too tightly to CompileOnDemandLayer. Does this alternative implementation of getLogicalModuleResourcesForSymbol work for you (unfortunately I don't have a local test case for this yet): LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool

It does work. I just tested it on my JIT. Thanks! As for the part that couples them too tightly, would you recommend I just keep my own specialized version of CompileOnDemandLayer.h that includes this functionality, or do you have any ideas for a cleaner way to do this? I've noticed a couple of people asking for support for updating stub pointers for functions that are optimized at runtime,

The patch looks incorrect. The code just needs to handle \1 properly and clang extended to add explicit \1 to the names which does not require mangling. I do not think that moving whole mangling to clang is a good idea, because then everyone who uses LLVM to call WinApi functions will need to mangle by hands. On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov <timurrrr at google.com>

Hi Sean, As for the part that couples them too tightly, would you recommend I just > keep my own specialized version of CompileOnDemandLayer.h that includes > this functionality, or do you have any ideas for a cleaner way to do this? My apologies - I wasn't very clear in my description of the issue. The only sense in which your original patch was tightly coupled was that it had

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole

On Feb 15, 2011, at 3:10 AM, Patrick Simmons wrote: > I have encountered a need for manually generating the mangled name of an > arbitrary C++ function. The only way I currently know how to do this is > to generate a dummy C++ source file, compile it, and look at the > output. This approach is so ugly that I would like for it never to see > the light of day. The c++filt tool

On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: >> My question: Is there an easy way of disabling the name-mangling part >> but keep the rest of the CC that I missed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like

On Aug 31, 2010, at 9:54 AM, Rafael Espindola wrote: > On 19 August 2010 01:25, Guoliang Jin <jingl1345 at gmail.com> wrote: >> Hi, >> >> I am using gold plugin with the option "-use-gold-plugin >> -Wl,-plugin-opt=also-emit-llvm" to compile apache. >> >> I objdumped the final executable httpd to httpd.S. >> >> I also compiled

So I was taking a look at Microsoft C++ ABI support while on vacation, and ran into a major issue. Given the following llvm-ir: $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft ; ModuleID = 'mangling.cpp' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-

No, the LLVM Mangler class really only does low-level manglings like '_' prefixing, stdcall mangling on Windows, and escaping funny symbols. The Clang mangler, however, does what you want. But, you'll need to feed it a clang AST in order to get a name out. Depending on the parameters of your function, this may be easy or hard. On Thu, May 9, 2013 at 8:38 AM, B B <blackbox.dev.ml