similar to: [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF

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 supporting mingw-w64 via > compiler-rt and now we are able to build a full mingw-w64 toolchain without > gcc :) > With great help from yaron and rnk. > >

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

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

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

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. One thing we need to do is that currently we construct the import descriptor directly from short import libraries. We don't create

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

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 is not hard. > > > I

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

Here's some C code: extern void *GetStdHandle(unsigned int nStdHandle); extern void ExitProcess(unsigned int exit_code); extern char WriteFile(void *HANDLE, const void * lpBuffer, unsigned int nNumberOfBytesToWrite, unsigned int *lpNumberOfBytesWritten, void *lpOverlapped); static const char *message_ptr = "hello\n"; static const unsigned int message_len = 6;

+ruiu and compnerd, since there might be an lld issue here. A slightly simpler example. This is all x86_64; I haven't tried x86. % cat imp.c __declspec(dllimport) void ExitProcess(unsigned exitCode); int mainCRTStartup() { ExitProcess(0); } % cat kernel32.def LIBRARY kernel32 EXPORTS ExitProcess % dlltool –d kernel32.def –l kernel32.lib % cl /Zl /c imp.c % link /subsystem:console imp.obj

Hi, I have gnuwin32 (b18) and the rw0613b.zip version of R. With regards to (re)making the dynload dll demo given (zero.dll) could anyone tell me what the command line for the makefile should be. ie, make -f Makefile.in ...? Thanks for any help -- Douglas -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read

Hi Martell, Sorry for the belated response. I missed this email. I took a quick look at the library file you have attached and noticed that the file consists of regular object files. LLD expects that all dllimported symbols are described using "short import library" (PE/COFF spec 7). Because I didn't test LLD with dlltool-style archive files, it's no surprise that it didn't

Hi Ivan, :) For testing purposes, I've managed to make the old COFF linker work with a > simple test case > Have you got patches for this that I can look at ? Had to make two little changes, and link the exe manually, because the > linker doesn't understand the GNU flags > I've solved the issue of having a GNU driver for the linker so that's not an issue anymore I

Dear R Users, I have created a 1500 x 20000 data frame - DataSeq. Each of the 1500 rows represents a data sequence. I have another data frame iData that stores the information of these 1500 data sequences in the same order, for example, condition, gender, etc. If I use "subset" to select certain groups within iData according to some criteria that I have set, e.g. condition, gender Then

Hi, I wish to compute multivariate test statistics for a within-subjects repeated measures design with anova.mlm. This works great if I only have two factors, but I don't know how to compute interactions with more than two factors. I suspect, I have to create a new "grouping" factor and then test with this factor to get these interactions (as it is hinted in R News 2007/2), but

I have design with two repeated-measures factor, and no grouping factor. I can analyze the dataset successfully in other software, including my legacy DOS version BMDP, and R's 'aov' function. I would like to use 'Anova' in 'car' in order to obtain the sphericity tests and the H-F corrected p-values. I do not believe the data are truly deficient in rank. I

Hi Martell. I too was trying to make the new COFF linker recognize the libraries generated by binutils, but it wasn't resolving the DLLs, just like you described. Apparently it is not identifying the libraries as import libraries but archives. For testing purposes, i've managed to make the old COFF linker work with a simple test case. Had to make two little changes, and link the exe

Hey llvm'ers, I have been working on a dlltool replacement for llvm. Here is my initial differential https://reviews.llvm.org/D29892 It is based on some functionality that already exists in lld. I added functionality to support, PE COFF Weak Externals and of course a front end to actually use it. I believe the work here can also be used for llvm-lib and lessen the load on lld. I would like

Env: R 2.8.1, Win Xp, Eclipse/StatET In a .Rd file, I have an example containing the lines: # calculate Y M, using polynomial contrasts trends <- as.matrix(VocabGrowth) %*% poly(8:11, degree=3) colnames(trends)<- c("Linear", "Quad", "Cubic") [At the risk of a long message, I'll append the complete .Rd file at the end of this message, in case this was

Hey Rui, > I wonder how llvm-dlltool would fit in the entire picture of mingw > support. I don't think dlltool is the last missing piece. What do you need > to do other than that to fully support mingw using LLVM toolchain? Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to