search for: martellmalon

Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect

...ies. 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 default build :) On Tue, Nov 3, 2015 at 6:30 PM, Chris Bieneman <beanz at apple.com> wrote: > > On Nov 3, 2015, at 9:24 AM, Martell Malone <martellmalone at gmail.com> > 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. &...

...to this http://reviews.llvm.org/D14290 On Tue, Nov 3, 2015 at 6:15 PM, C Bergström <cbergstrom at pathscale.com> wrote: > On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 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 > >...

...sts.cs.uiuc.edu/pipermail/llvmdev/2014-April/072145.html> ... > > Vadim Yaron also pointed out that int main() { throw 1; } generates two .seh_endprologue instructions. I still did not fix this bug. Regards, Kai > > > On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone > <martellmalone at gmail.com <mailto:martellmalone at gmail.com>> wrote: > > Hi, > > I'd like to submit a patch to match the clang patch on the front end. > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn'...

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 things. > > Since rL289280 I can no longer link programs with the mingw-crt be...

...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? > > On Mon, Feb 13, 2017 at 5:37 PM, Martell Malone <martellmalone at gmail.com> > wrote: > > 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...

...41 b9 00 00 00 00 movl $0, %r9d 302f: e8 d4 ff ff ff callq -44 3034: b9 00 00 00 00 movl $0, %ecx 3039: e8 c2 ff ff ff callq -62 So I am fairly certain this is the cause. Many Thanks Martell On Thu, Jul 23, 2015 at 4:22 PM, Martell Malone <martellmalone at gmail.com> wrote: > I forgot to attach the notes.txt with the objdump. > > > On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> Hi again rui, :) >> >> I've got all the patches into llvm and clang for suppo...

...g that was presumably introduced by r289280. If you just want to get past this issue though, implementing it would probably just involve downgrading the fatal error in SymbolTable::reportDuplicate to a warning if /FORCE:MULTIPLE is passed. Peter On Sun, May 21, 2017 at 7:05 AM, Martell Malone <martellmalone at gmail.com> wrote: > Hey Peter, > > Currently I still use the custom frontend I have for using lld so it > wouldn't be much use to do that. > I'm looking to get all the other components merged before I submit an in > process shim like Rui suggested. > > I thin...

...ode 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 <martellmalone at gmail.com> > wrote: > > 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. > > > What is the short-term plan? I don't think you can submit this > llvm-dlltool as-is because it...

...or injection. Should we be using the stub code provided in the text section or should we just ignore it and use the one in lld They are the same anyway but its just interesting how the dlltool version gives us that option. Kind Regards Martell On Fri, Jul 24, 2015 at 10:52 AM, Martell Malone <martellmalone at gmail.com> wrote: > 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 &g...

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

..._}{foo,bar}. > > Do you know how to define symbol aliases in COFF? If you don't, take a > look a member of oldnames.lib (which comes with MSVC). That library file > defines bunch of aliases, and you can do the same thing. > > On Thu, Aug 13, 2015 at 2:25 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> 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 t...

...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: > > 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 > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > w...

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 >>> foo.exe foo.obj" and then call lld::COFFF:link(). It doesn'...

...hange I had to make to support this was alter ming-w64 crt to change all references from __image_base__ to _ImageBase to support that That should be fine. Great On Mon, Feb 13, 2017 at 9:34 PM, Rui Ueyama <ruiu at google.com> wrote: > On Mon, Feb 13, 2017 at 1:16 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> 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...

...ns from short import libraries. That means we > cannot mix dlltool-style and short import libraries at this moment. We need > to do something for that. Except that, supporting dlltool-style libraries > should be straightforward. > > On Sat, Jul 25, 2015 at 3:10 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> 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...

...b.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. > > > On Thu, Aug 13, 2015 at 2:04 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> Hi Rui, >> >> I have finished my tool to generate short import libs for mingw-w64. >> >> It works fine with lld for actual symbols. >> But it seems lld segfaults when I try to use and an alias as we discussed >> before....

On Sat, Jul 25, 2015 at 5:24 PM, Martell Malone <martellmalone at gmail.com> wrote: > 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...

> > For example the gnu linker provides the section with the stub code and the > offset for injection. Meant to say dlltool here not gnu linker :) On Sat, Jul 25, 2015 at 11:17 AM, Martell Malone <martellmalone at gmail.com> wrote: > 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...

...lt;yaron.keren at gmail.com> wrote: > This test results in UNSUPPORTED on my system, since config.enable_ffi = > "OFF". This is the result of LLVM_ENABLE_FFI which is OFF by default. Is it > turned ON in your build? > > > 2015-07-28 17:32 GMT+03:00 Martell Malone <martellmalone at gmail.com>: > >> 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/Int...