search for: maches

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 12:55:20 PM > Subject: Re: lld and thread over-subscription > >

On Thu, Oct 1, 2015 at 10:55 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I honestly think that the ulimit of 1024 max threads is too strict for 48 > core machine. Processes are independent each other, so it is not strange > for them to spawn as many threads as the number of cores. What's the reason > you cannot increase the limit? > Yeah, this is

Hi Rui, et al., I was experimenting yesterday with building lld on my POWER7 PPC64/Linux machine, and ran into an unfortunate problem. When running the regressions tests under lit, almost all of the tests fail like this: terminate called after throwing an instance of 'std::system_error' what(): Resource temporarily unavailable ... 5 libc.so.6 0x00000080b7847238 abort +

Hi, I setup two sshd instance (using OpenSSH_3.5p1 bins on redhat7.2 kernel 2.4.20-19.7smp ) in order to achieve differnet sshd settings (e.g use different auth.method) on two different network interfaces (both on port 22). For example to setup Hostbased authetication on the 1st sshd and RSA pub. key auth. on the second: The 1st instance config file /etc/ssh/sshd_config looks like:

Hi, I''m glad to announce that I have mostly finished a port of GNU Mach to Xen, so that GNU/Hurd/Mach/Xen now works :) Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi Rui, The motivation would be primarily that LLVM/Clang/LLD are community projects such that if I or someone in the community added support for e.g. symbol aliases, then it could be reviewed and potentially merged. ld64 on the other hand does not have a community process for patch submission and code review that I am aware of so its unlikely that if someone from the community came up with a

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

Hello When i try to make world (any) from xen-3.0.2 to xen-unstable-src I gat following error : gcc -O2 -fomit-frame-pointer -DNDEBUG -m64 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/test1/xen-unstable/xen/include

Hi, I'm going to implement Mach-O support in llvm-objcopy. Before working on this, I'd like to hear your thoughts how llvm-objcopy should handle Mach-O section names. By convention, Mach-O section names are denoted by "<segment name>,<section name>". However, GNU objcopy renames them in the following rule [1]: - If the section name is well-known, rename it to an

This error came up after half-hour of installing wine: new-host:~ staruhinevgenij$ sudo port install wine Password: ---> Building wine with target depend all Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine/work/wine-1.0.1" && make depend all "

Hi Folks, I have a question regarding LLD support for ld64 mach-o linker synthesised symbols. I did a quick search of the LLD source and I can not find support for them so before I start trying to use lld I thought I would ask. I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o

On 2020-02-28, James Y Knight via llvm-dev wrote: >Nice! > >Your plan sounds great, and it'll be awesome to finally have a good MachO >LLD available. > >On Fri, Feb 28, 2020 at 4:32 PM Shoaib Meenai via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> We’re planning to contribute a new implementation of LLD for Mach-O, using

> > I for one would really like to see object generation become a fully > working feature of the llvm toolchain. Actually, a related thing I've been curious about is the difference between the output of the llvm-gcc-4.2 front end on the Mac and a regular plain vanilla bit code file. The former file can be named a .o and the platform linker now knows how to do LTO while linking

Hey all, I was trying to install wine on OS X.4.11 using MacPorts - it had been running for about forty-five minutes - when my battery died. Nevermind the stupidity of not noticing the cord unplugged. Anyway, the install did not finish and now, when I try to "sudo port install wine" I get: Blahman:~ Blahman$ sudo port install wine ---> Building wine Error: Target

Given that the xenvm machine is based on vexpress but with an extremely limited selection of peripherals (the guest is supposed to use virtual devices instead), add "xen,xenvm" to the list of compatible machines in mach-vexpress. Changes in v2: - remove include skeleton; - use #address-cells = <2> and #size-cells = <2>; - remove the debug bootargs; - use memory@80000000

> On May 23, 2019, at 2:05 AM, James Henderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I discussed this with Seiya off the mailing list yesterday, and this was the suggestion we came up with, on the basis that GNU objcopy has support for the renaming for GDB support, but it might be confusing to people who are new to the system, so we provide a more expected output

I'd be interested in the existence of a high-quality, open-source, portable linker for apple platforms, but not enough to help make that happen. If I _was_ gonna work on something related to that, I'd probably be inclined to instead add any required features to allow an ELF linker to target a notional darwin-elf target, and to have clang emit darwin-elf object files, and then write a

Hello all, I'm trying to better understand the state of Mach-O support in lld. The lld docs state that "the linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and WebAssembly in descending order of completeness." [1] True to that statement, I found an email on this list from Jan 2018 stating that "MachO support in lld is not really ready for real world usage. It was

Hi all, We’re planning to contribute a new implementation of LLD for Mach-O, using the same design as the COFF and ELF ports. This design has proven to work very well for those ports, and we’re keen to explore it for Mach-O as well. Our work is based on an initial prototype created by Peter Collingbourne and Rui Ueyama. Our initial commit is up for review at https://reviews.llvm.org/D75382.