similar to: lld-link with MSVC6 object files

The CodeView library in LLVM only supports Codeview C13 types, that is, MSVC 7.0 / Visual Studio 2002 or after. De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David Blaikie via llvm-dev Envoyé : September 30, 2019 2:38 PM À : Paul Moran <bankybooks at gmail.com>; Rui Ueyama <ruiu at google.com> Cc : llvm-dev at lists.llvm.org Objet : Re: [llvm-dev] lld-link

On Mon, Sep 30, 2019 at 2:07 PM Paul Moran <bankybooks at gmail.com> wrote: > MSVC 6 is 1998 not 1989 :) > Ah, I just glanced briefly at the Wikipedia article ( https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B ) & misread the "C 6.0" and didn't notice it was distinct from "Visual C++ 6.0" - thanks for the catch! > > The latest MSVC linker can

I would expect it to be able to link the object file, even if it ignored debug info. It's a bit strange that it complains about bad file magic. It might be tricky to get debug information working and produce a valid PDB file since that is pretty old and the format has changed both with how it was stored in the object file itself as well as the format of the PDB file. My guess is that the

I have the most edge of edge use cases :). I am recovering the lost source code to an application built with MSVC 6. However because I want to produce byte for byte exact output I need to ensure that the import table is in the same order as the original binary. Since the MSVC6 linker has no way of doing this I figured I could hack this feature into lld-link. I need to also set the PDB path in the

That isn't the case but my idea is that I can hack a copy of lld-link to produce the same output. Since the other option is to use the MSVC6 linker which will do things like randomly re-order the order of imported functions and the likes. I can't change that without doing something crazy like reverse engineering the linker and patching something in there to force a particular ordering. I

Hi everyone, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl

Sorry I missed that important detail. The relevant part of the command line is: -cc1 -S -triple i386-pc-win32 I don't expect it matters if it's for Windows or Linux in this case. On Fri, Sep 14, 2018 at 9:16 PM David Blaikie <dblaikie at gmail.com> wrote: > Can't say I've observed that behavior (though I'm just building from > top-of-tree rather than 6.0,

Hi Duncan, David, Sean. Thanks for your reply. > It'd be interesting if you could find a design that also treated these > the same: > > (B ^ A) | ((A ^ B) ^ C) -> (A ^ B) | C > (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C > (B ^ A) | ((C ^ A) ^ B) -> (A ^ B) | C > > I.e., `^` is also associative. Agree with Duncan on including associative operation too.

On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > Uh. Turns out that if I hide the pointer to @foo from LLVM by passing it > through an opaque identity function ... then everything works fine. > > Is this a bug in LLVM or is there some magic involving globals I'm > misunderstanding? > This looks like a bug in the handling of

That's useful to know that the static compilation code path works. Furthermore, as expected from that: 52: c7 05 04 00 00 00 d5 00 00 00 movl $213, 4 00000054: IMAGE_REL_I386_DIR32 _foo It looks like the offset `4` of the second field of your struct is correct in the object file, so this does seem to be a problem in the JIT-specific linking/loading.

My code was hinky, but only in the sense that I was accidentally duplicating the definition variable in the module where the function was. With only the declaration in the second module loading the bitcode reproduces the issue. Managed an lli reproduction: $ cat jit-0.ll target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32" target triple =

Hello all, In r223757 I've committed a patch that performs, for the 32-bit x86 calling convention, the transformation of MOV instructions that push function arguments onto the stack into actual PUSH instructions. For example, it will transform this: subl $16, %esp movl $4, 12(%esp) movl $3, 8(%esp) movl $2, 4(%esp) movl $1, (%esp) calll _func addl $16, %esp

I've modified llvm to emit vc++ compatible SEH structures for my personality on x86/Windows and my handler works fine, but the only thing I can't figure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax

Thanks Sean for the reference. I will go through it and see if i can implement it for generic boolean expression minimization. Regards, Suyog On Wed, Aug 13, 2014 at 2:30 AM, Sean Silva <chisophugis at gmail.com> wrote: > Re-adding the mailing list (remember to hit "reply all") > > > On Tue, Aug 12, 2014 at 9:36 AM, suyog sarda <sardask01 at gmail.com> wrote:

On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > For now I'm just going to attempt to work around it like this in the > kernel, so I can concentrate on the retpoline bits: >  http://david.woodhou.se/clang-percpu-hack.patch 32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0 (and the above patch) it does. I'm rebuilding a Release build of

On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> 7.0.0-rc1 was just tagged (from the branch at r338847). >> >> It's early in the release process, but I'd like to find out what the >> status is of the branch

Which performance guidelines are you referring to? I'm not that familiar with decade-old CPUs, but to the best of my knowledge, this is not true on current hardware. There is one specific circumstance where PUSHes should be avoided - for Atom/Silvermont processors, the memory form of PUSH is inefficient, so the register-freeing optimization below may not be profitable (see 14.3.3.6 and

Hi Rui, Peter, You know I'm enabling the "clang-cl + lld-link" toolchain for Uefi firmware. I meet a problem that the lld-link fails to link 32bits assembly functions, but can link 64bits assembly functions successfully. I need your suggestion. Below is an example to show my problem in linux. The example has two only source files: main.c and foo.nasm. $ cat main.c void Foo (void);

On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > For now I'm just going to attempt to work around it like this in the > > kernel, so I can concentrate on the retpoline bits: > >  http://david.woodhou.se/clang-percpu-hack.patch > > 32-bit doesn't boot. Built without

Hi, All, Duncan, Rafael, David, Nick. This is regarding pattern matching in InstructionCombine pass. We use 'match' functions many times, but it doesn't do the pattern matching effectively. e.x. Lets take pattern : (A ^ B) | ((B ^ C) ^ A) -> (A ^ B) | C (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C Both the patterns above are same, since ^ is commutative in Op0. But,