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 integration of CodeView debugging information into LLVM, which somewhat ties in with this. This was expressed as a regular BNF grammar, so it should be possible to create a clean-room implementation of both the “mangler” and “de-mangler” from that BNF definition if it still exists in that form. Does the recently added CodeView debug information not provide this description (I admit I haven’t looked)? Certainly tools like ‘c++filt’ do not know about the Microsoft name decoration scheme, but LLVM does know how to mangle the names using the VC++ ABI, and since the mangling follows a regular grammar, the de-mangling should be relatively straight-forward to implement. All the best, MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Davide Italiano via llvm-dev Sent: 19 June 2017 19:00 To: Rui Ueyama <ruiu at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] VC C++ demangler On Mon, Jun 19, 2017 at 10:53 AM, Rui Ueyama via llvm-dev < <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org> wrote:> Hi,>> We have a demangler for the Itanium ABI, but looks like we don't have> one for the MSVC-style symbols. Is there any good demangler we can> import to LLVM?>> If there's no suitable demangler, I'd like to write one. Currently, we> are using `UnDecorateSymbolName` function, but the function is> available only on Windows (which is problematic when you are doing a> cross-build), and the function is not thread-safe. These two seem to> be an enough reason to have our own demanler.>I'm not aware of a suitable one, currently. I agree it would be very useful to have. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare _______________________________________________ LLVM Developers mailing list <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> 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/20170619/8d12252d/attachment.html>
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 change between Windows and non-Windows platforms, but it probably shouldn't be hard. On Mon, Jun 19, 2017 at 12:34 PM, Martin J. O'Riordan < martin.oriordan at movidius.com> wrote:> 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 integration of CodeView > debugging information into LLVM, which somewhat ties in with this. > > > > This was expressed as a regular BNF grammar, so it should be possible to > create a clean-room implementation of both the “mangler” and “de-mangler” > from that BNF definition if it still exists in that form. Does the > recently added CodeView debug information not provide this description (I > admit I haven’t looked)? > > > > Certainly tools like ‘c++filt’ do not know about the Microsoft name > decoration scheme, but LLVM does know how to mangle the names using the > VC++ ABI, and since the mangling follows a regular grammar, the de-mangling > should be relatively straight-forward to implement. > > > > All the best, > > > > MartinO > > > > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Davide Italiano via llvm-dev > Sent: 19 June 2017 19:00 > To: Rui Ueyama <ruiu at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] VC C++ demangler > > > > On Mon, Jun 19, 2017 at 10:53 AM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hi, > > > > > > We have a demangler for the Itanium ABI, but looks like we don't have > > > one for the MSVC-style symbols. Is there any good demangler we can > > > import to LLVM? > > > > > > If there's no suitable demangler, I'd like to write one. Currently, we > > > are using `UnDecorateSymbolName` function, but the function is > > > available only on Windows (which is problematic when you are doing a > > > cross-build), and the function is not thread-safe. These two seem to > > > be an enough reason to have our own demanler. > > > > > > > I'm not aware of a suitable one, currently. I agree it would be very > useful to have. > > > > -- > > Davide > > > > "There are no solved problems; there are only problems that are more or > less solved" -- Henri Poincare ______________________________ > _________________ > > LLVM Developers mailing list > > 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/20170619/9ab3f3d2/attachment.html>
On Mon, Jun 19, 2017 at 12:48 PM, Rui Ueyama <ruiu at google.com> 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 change between Windows and > non-Windows platforms, but it probably shouldn't be hard. >Something you may want to keep in mind while prototyping is that writing a demangler in C++ (or any other unsafe language) is particularly annoying, so you may want to keep fuzzers and sanitizers always in your toolbox. The itanium demangler currently in tree suffers from all kinds of bugs/vulnerabilities, FWIW. -- Davide
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 change between Windows > and non-Windows platforms, but it probably shouldn't be hard. >Just to be clear - once LLVM has its own demangler, it should probably use it on all platforms, so there'd be no worry about different behavior between LLVM on Windows and LLVM elsewhere. But that said, it's probably still important/worthwhile to make sure it's consistent with the platform demangler.> > On Mon, Jun 19, 2017 at 12:34 PM, Martin J. O'Riordan < > martin.oriordan at movidius.com> wrote: > >> 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 integration of CodeView >> debugging information into LLVM, which somewhat ties in with this. >> >> >> >> This was expressed as a regular BNF grammar, so it should be possible to >> create a clean-room implementation of both the “mangler” and “de-mangler” >> from that BNF definition if it still exists in that form. Does the >> recently added CodeView debug information not provide this description (I >> admit I haven’t looked)? >> >> >> >> Certainly tools like ‘c++filt’ do not know about the Microsoft name >> decoration scheme, but LLVM does know how to mangle the names using the >> VC++ ABI, and since the mangling follows a regular grammar, the de-mangling >> should be relatively straight-forward to implement. >> >> >> >> All the best, >> >> >> >> MartinO >> >> >> >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >> Davide Italiano via llvm-dev >> Sent: 19 June 2017 19:00 >> To: Rui Ueyama <ruiu at google.com> >> Cc: llvm-dev <llvm-dev at lists.llvm.org> >> Subject: Re: [llvm-dev] VC C++ demangler >> >> >> >> On Mon, Jun 19, 2017 at 10:53 AM, Rui Ueyama via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> > Hi, >> >> > >> >> > We have a demangler for the Itanium ABI, but looks like we don't have >> >> > one for the MSVC-style symbols. Is there any good demangler we can >> >> > import to LLVM? >> >> > >> >> > If there's no suitable demangler, I'd like to write one. Currently, we >> >> > are using `UnDecorateSymbolName` function, but the function is >> >> > available only on Windows (which is problematic when you are doing a >> >> > cross-build), and the function is not thread-safe. These two seem to >> >> > be an enough reason to have our own demanler. >> >> > >> >> >> >> I'm not aware of a suitable one, currently. I agree it would be very >> useful to have. >> >> >> >> -- >> >> Davide >> >> >> >> "There are no solved problems; there are only problems that are more or >> less solved" -- Henri Poincare >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing list > 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/20170620/23907f93/attachment.html>