similar to: [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

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

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>

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 Timur since he might know more about this. On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at klickverbot.at>wrote: > On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: > >> My question: Is there an easy way

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

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

Hi all, I'm currently working on getting our (LDC) compiler to run on Win32/MinGW, now that DW2-style EH is available for it. The D programming language has a feature equivalent to LLVM module level inline assembly, so we need to at least partly follow the x86 D calling convention (http://dlang.org/abi.html). Most notably, the ABI mandates that the callee cleans the stack. On the various

Hi all, It seems like the llvm-3.3-* packages are gone from the Ubuntu Precise APT repository, http://llvm.org/apt/precise/. Is this on purpose? Any recommended replacements? (Launchpad?) Thanks, David

There is a description of all the possible linkage types at http://llvm.org/docs/LangRef.html#linkage – does this answer your question? (Basically, an extern_weak resp. ExternalWeakLinkage symbol becomes null instead of being an undefined reference) David On 3/16/11 7:06 PM, Junjie Gu wrote: > What is the difference between WeakAnyLinkage and ExternalWeakLinkage > ? They are defined

What is the difference between WeakAnyLinkage and ExternalWeakLinkage ? They are defined in GlobalValue.h. Thanks Junjie

The following piece of IR is a fixed point for opt -std-compile-opts/-O3: --- target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: nounwind readonly define i32 @get32Bits(i8*

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

+LLVMdev On Aug 4, 2012, at 9:45 AM, João Matos wrote: > Charles Davis did a lot of work on Win64 SEH support in LLVM, check commits r131652-r132880. > > As I haven't tested it yet, what exactly is broken? It's not finished yet. All the stuff for assembly code that uses Win64 EH is done, but not the code-gen-side stuff (cf. Win64Exception class in CodeGen). I was about to

For the current project I'm working on (https://github.com/mono/CppSharp) having the flags to change the ABI based on a GCC version would be ideal. If there are no flags, this means we must implement some logic to change the calling conventions of methods manually to how they were pre-4.7. Should not be a lot of work but it'd be best to contain all the C++ ABI details inside Clang itself.

On Aug 6, 2012, at 1:03 PM, João Matos wrote: > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. Glad you agree. We really shouldn't be replicating information in the frontend; this very error

> > I'm not sure we would want to store the MCInst(s) in the AST. After we're > done with semantic checking and we've created the IR representation (with > inputs, outputs, clobbers, constraints, etc.), I don't think there's a > reason for the MCInst(s) to persist. > I was assuming that MCInst would already provide a lot of the needed information, like

On 10 December 2013 09:16, João Matos <ripzonetriton at gmail.com> wrote: > For the current project I'm working on (https://github.com/mono/CppSharp) > having the flags to change the ABI based on a GCC version would be ideal. If > there are no flags, this means we must implement some logic to change the > calling conventions of methods manually to how they were pre-4.7.

The tool uses Clang to parse the user's C/C++ code to get the calling conventions from the AST, so they need to match the ones in the compiled libraries to allow correct interop. If the user libraries were compiled with GCC 4.6 (which stills seems used by some MinGW distros) then once we upgrade to the latest Clang we'll start getting thiscall CC instead of the correct one used pre-4.7 for

Hi! I try to add more functionality to Win64 exception handling, based on the posted patches from Charles Davis and João Matos. But I have a question about how to map SEH handling to LLVM IR. The basic structure of SEH in C is as follows: __try { // Do something. } __except (filter(GetExceptionCode(), GetExceptionInformation())) { // Handle exception } How to

Hi Timur, There's also a pending patch adding CodeView support in Phab: http://llvm-reviews.chandlerc.com/D165 Does your patch provide just a subset of the CodeView debug info provided in the other patch? Looking at the patch, I think the approach the other patch took of abstracting the emission of debug information is a bit cleaner and it will probably make life easier when adding more

> > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. > In the above example, the two asm statments are not valid assembly. > Thus, the AsmParser cannot parse these statements without some >