search for: _xx_

Why is it that high (>127) bytes in symbol names get mangled by LLVM into _XX_, where XX is the hex representation of the character? Is this required by ELF or some similar standard? This behavior is inconsistent with GCC. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120330/856...

On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote: > Why is it that high (>127) bytes in symbol names get mangled by LLVM into > _XX_, where XX is the hex representation of the character? Is this required > by ELF or some similar standard? This behavior is inconsistent with GCC. I think it's just so that we have a way to actually write out the symbol into the assembly file. What does gcc do? -Eli

On Fri, Mar 30, 2012 at 15:22, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> > wrote: > > Why is it that high (>127) bytes in symbol names get mangled by LLVM into > > _XX_, where XX is the hex representation of the character? Is this > required > > by ELF or some similar standard? This behavior is inconsistent with GCC. > > I think it's just so that we have a way to actually write out the > symbol into the assembly file. What does gcc do? >...

...t code I stuck a '\1' character in front of the name to prevent LLVM's mangler from doing anything to it (see lib/AST/MicrosoftMangle.cpp:162). (I knew the prepending of '_' characters was a problem, but I didn't know LLVM magically transformed chars it doesn't like into _xx_.) That is a magic marker that says "this is the literal name of this symbol, don't mangle it in the usual way." > > It looks like for some reason that the '\1' character isn't getting emitted. I wish I had an answer for you, but I can't debug this because I don&...

...t code I stuck a '\1' character in front of the name to prevent LLVM's mangler from doing anything to it (see lib/AST/MicrosoftMangle.cpp:162). (I knew the prepending of '_' characters was a problem, but I didn't know LLVM magically transformed chars it doesn't like into _xx_.) That is a magic marker that says "this is the literal name of this symbol, don't mangle it in the usual way." It looks like for some reason that the '\1' character isn't getting emitted. I wish I had an answer for you, but I can't debug this because I don't run...

...t code I stuck a '\1' character in front of the name to prevent LLVM's mangler from doing anything to it (see lib/AST/MicrosoftMangle.cpp:162). (I knew the prepending of '_' characters was a problem, but I didn't know LLVM magically transformed chars it doesn't like into _xx_.) That is a magic marker that says "this is the literal name of this symbol, don't mangle it in the usual way." >> >> It looks like for some reason that the '\1' character isn't getting emitted. I wish I had an answer for you, but I can't debug this becaus...

...at 15:22, Eli Friedman <eli.friedman at gmail.com> wrote: >> >> On Fri, Mar 30, 2012 at 12:12 PM, Sean Hunt <scshunt at csclub.uwaterloo.ca> >> wrote: >> > Why is it that high (>127) bytes in symbol names get mangled by LLVM >> > into >> > _XX_, where XX is the hex representation of the character? Is this >> > required >> > by ELF or some similar standard? This behavior is inconsistent with GCC. >> >> I think it's just so that we have a way to actually write out the >> symbol into the assembly file....

...backend tries to define the mangled symbol name twice, since "a(b" mangles to "a_28_b". Was it a conscious design choice to do it this way? Perhaps to save the time of verifying the uniqueness of the symbol? Or is the idea that you can always de-mangle by searching for "_XX_" sequences and replacing those with the ASCII value of XX? -- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130822/c7be4d3c/attachment.html>

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-

...t code I stuck a '\1' character in front of the name to prevent LLVM's mangler from doing anything to it (see lib/AST/MicrosoftMangle.cpp:162). (I knew the prepending of '_' characters was a problem, but I didn't know LLVM magically transformed chars it doesn't like into _xx_.) That is a magic marker that says "this is the literal name of this symbol, don't mangle it in the usual way." >>> >>> It looks like for some reason that the '\1' character isn't getting emitted. I wish I had an answer for you, but I can't debug this...