similar to: [LLVMdev] [PATCH] Seh exceptions on Win64

Hi, On 15.04.2014 23:44, Vadim Chugunov wrote: > Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so

> > I will not be stripping out any of the existing CMake. If we go down this > path what I’m going to do is refactor the CMake to produce to logically > separated projects so that the builtins can be built with or without the > runtime libraries. It will all still be CMake-based. Sorry. s/stripping/seperating/g I was still thinking about the stripping of the IOS build from the OSX

Would it be possible to share a repro.tar file created with /linkrepro so that we can reproduce the problem? Peter On Thu, May 11, 2017 at 3:00 AM, Martell Malone <martellmalone at gmail.com> wrote: > There are a few things running in parallel and thanks for taking the time > to review and help me get this in tree. > I wanted to follow up with a question on the linker side of

After some more digging and creating a few testcases in lld I have narrowed it down to The fact that dlltool generates Contents of section .idata$7: 0000 55534552 33322e64 6c6c0000 USER32.dll.. Where as lld expects Contents of section .idata$6: 0000 55534552 33322e64 6c6c0000 USER32.dll.. I recreated the hello64.test using dlltool for the lib and here is the asm dump of

Yes, that would be the long term plan. llvm-link ideally would share the same library. I'm not sure where it should live though. On Tue 14 Feb 2017 at 01:49, Rui Ueyama <ruiu at google.com> wrote: > I took a look at the code. Looks like you need a library to create import > library files in LLVM and use that from llvm-dlltool and LLD. Is that what > you are planning? > >

Hi Martell, r289280 was not intended to be a significant functional change in the sense that it would cause programs to fail to link, so this may be a bug I introduced in r289280 (or one of the followup patches, which also changed link order). How is crt0_c.c being added to the link? If crt0_c.c is supplying a definition of the main function I would expect it to be in an archive which would

Ohh nice. With that method I can support it without upsetting ld users by introducing an api breakage. On Tue 14 Feb 2017 at 01:32, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:26 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >

> > Cool. This then makes your other point about requiring LLVM tools less of > an issue because the out-of-tree builds can use whatever tools you choose. > We just need to make the builtins work so that you don’t need them already > built. With that in mind for an intiial solution before you get to stripping out the cmake stuff so that it can do an out of tree bootstrap. I have

> > If you want to define an alias symbol "bar" to "foo" (which is an > extension you want to provide), one way is to create an object file that > defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo", > respectively, and add that object file to the import library. As a result, > the import library file

Well that means it would just be the only plan then. I assume the first step would be to move the code from lld into this new library and lld can use that? I can then re add the extra functionality for weak externals? We can then have lib and dlltool use this then. On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone

> > No, I meant an even thinner wrapper which textually translates arguments. > For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > with Config object nor LinkerDriver::run and have absolutely zero knowledge > on the internals of LLD. Ohh okay I misunderstood.

Hey guys, So I was able to modify dlltool to produce the exact same layout as lib.exe with the same section numbers etc. I've first managed to first create the correct section so that lld gives me link errors and then resolve those errors to create an exe. This is one thing that is still missing that sticks out like a sore thumb In the actual imports of the functions the objects are very

On Mon, Feb 13, 2017 at 5:20 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 13, 2017 at 4:46 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> No, I meant an even thinner wrapper which textually translates arguments. >>> For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o

On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at gmail.com> wrote: > Just as a point for building the builtins shouldn't we just need llvm-ar ? Thanks for pointing this out and I hope llvm-ar is up to the task. Even if targets must still port binutils, each step toward LLVM self-reliance is a step in the right direction. Without getting too far ahead of ourselves,

> > It's doable to support dlltool-style import libraries by LLD. .idata > sections in dlltool-style libraries are designed so that they will > naturally construct the import descriptor table by just sorting them by > section name. Supporting them is not hard. I don't really know my way around the code base of COFF well enough todo this myself. If you can point me in the

> > The header of libuser32b.a says that it defines MessageBoxB and > __imp_MessageBoxB, but the import library file in the archive actually > defines MessageBoxA (not B). So the archive file is broken. You may want to > fix the header and try again. Yes this is how I done the alias. If you consider this invalid then look at libuser32.a The header defines MessageBoxA and

> > I wonder if it can be a wrapper for LLD/COFF. It can be an in-process > wrapper, meaning that you could add a main function for mingw which > translates all arguments into the MSVC style and then invoke the COFF > linker's main function. That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I

Hi Rui, Thanks for getting back to me on this Do you think that you can make dlltool to generate short import libraries? > If you can, it would be the easiest way to solve the issue. > On my current tests ld seems to not like libraries built with short import libraries so this would require an ABI break in binutils. dlltool has support for loads of legacy targets and changing this would

> > Is it turned ON in your build? > Yes it is turned on in my build here is my build script PATH=/mingw64/bin:$PATH FFI_INCLUDE_DIR="$(pkg-config --cflags libffi)" > FFI_INCLUDE_DIR=$(echo $FFI_INCLUDE_DIR | sed 's|-I||g') > > /mingw64/bin/cmake.exe \ > -G"MSYS Makefiles" \ > -DCMAKE_MAKE_PROGRAM="/usr/bin/make.exe" \ >

Hi Yaron, I know you sent me some emails before about regression testing on MSYS2 So you might have some idea about this I am getting a regression error on check-llvm. With the llvm/trunk/test/ExecutionEngine/Interpreter/intrinsics.ll FAIL: LLVM :: ExecutionEngine/Interpreter/intrinsics.ll (7635 of 14266) > ******************** TEST 'LLVM :: >