similar to: [LLVMdev] C++ Name mangling

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

> 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. By the way, does anyone know of a project which *does* call into Clang's mangling framework from outside? I'd be interested to know purely out of curiosity. Cheers. Tim.

A long time ago, when I devised the grammar and structure of the Microsoft C++ name mangling scheme (decorated names), the document describing the object model and the name decoration scheme were made publically available. Perhaps this is still available publically, or perhaps Microsoft might be willing to share an up to date definition of the name-decoration grammar, especially in light of the

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

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

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 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 = >

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-

Hi all, Right now the Mangler::getValueName() method will produce something like "__unnamed_1_37" for a global value that doesn't have a name. This is wrong for Objective-C where CFStrings will get these labels, thus preventing the linker from coalescing them. [/tmp]> nm -s __DATA __cfstring -m foo.o 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0

Can symbols with external linkage but no name be converted to have internal linkage? Would that solve the problem? Dan On Nov 23, 2008, at 2:15 AM, Bill Wendling wrote: > Hi all, > > Right now the Mangler::getValueName() method will produce something > like "__unnamed_1_37" for a global value that doesn't have a name. > This is wrong for Objective-C where CFStrings

The symbols I'm interested in already have internal linkage (as you would expect). But because the mangler is in charge of assigning them names, they never seem to be decorated with the 'L' in front. . . . -bw On Mon, Nov 24, 2008 at 10:48 AM, Dan Gohman <gohman at apple.com> wrote: > Can symbols with external linkage but no name be converted > to have internal linkage?

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 Nov 24, 2008, at 11:07 AM, Chris Lattner wrote: > > On Nov 24, 2008, at 11:01 AM, Bill Wendling wrote: > >> The symbols I'm interested in already have internal linkage (as you >> would expect). But because the mangler is in charge of assigning them >> names, they never seem to be decorated with the 'L' in front. . . . > > If you use

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 generates demangled C++ names given the mangled ones, which is the opposite

On Nov 24, 2008, at 11:01 AM, Bill Wendling wrote: > The symbols I'm interested in already have internal linkage (as you > would expect). But because the mangler is in charge of assigning them > names, they never seem to be decorated with the 'L' in front. . . . If you use SET_DECL_ASSEMBLER_NAME (something like that) you can specify the full name for this stuff, including

On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> wrote: > Hello! > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > testing tools that would be based on LLVM libraries. > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ > names. Is it true, that LLVM doesn't have the code that is capable

On Mon, Jun 19, 2017 at 12:49 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have clang/lib/AST/MicrosoftMangle.cpp, so looks like what I should do > is to write code that do the reverse of it. One thing I should be careful > is to produce the exact same outputs as Microsoft's UnDecorateSymbolName > function would output so that the behavior doesn't

On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> > wrote: > > Hello! > > > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > > testing tools that would be based on LLVM libraries. > > I've noticed that llvm-nm

On Jul 4, 2012, at 12:43 PM, Michael Spencer wrote: > On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> wrote: >> Hello! >> >> We want to implement in-process symbolizer for {Address,Thread}Sanitizer >> testing tools that would be based on LLVM libraries. >> I've noticed that llvm-nm (as well as other tools) doesn't demangle

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, >