similar to: GNU Mach Xen port

pv-grub is also the best/only way to run hurd under xen: http://www.gnu.org/software/hurd/microkernel/mach/gnumach/ports/xen.html#index4h1 it's also the best way by far to run netbsd without a separate /boot Cheers, Brian Szymanski -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi! At night, when having my GNU Hurd maintainer hat on, I'm currently working on porting LLVM, clang et al. to x86-class systems using the GNU Hurd as their kernel, <http://www.gnu.org/software/hurd/>. In the following, I'll just use LLVM to refer to the whole suite of tools. To some extent, LLVM already works on GNU/Hurd; thanks for constructing it in a portable fashion. From

Hi, These patches are from Robert Bihlmeyer to make ssh build on Hurd. If you have queries about them, I suggest contacting debian-hurd at lists.debian.org. Cheers, Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-2.9-hurd.diff Url:

Hi, here's a patch so that ssh also supports hurd-i386. Thanks for incorporating. The patch comes from Robert Bihlmeyer <robbe at orcus.priv.at>. > openssh 2.2.0p1-1.1 does not build on the Hurd. The appended patch > fixes that. Changes in detail: > * PAM is not (yet?) supported, so the PAM dependencies are only put into > the control file on architectures != hurd-i386.

Hello all, I know that the question: Is it possible to run quemu inside Xen domU or run Xen domain 0 on quemu have discussed earlier in this mail list. As far as I remember this is possible except such a configuration where kquemu acceleration is in use. But what about HVM-capable systems? Please tell me are there the same restrictions for the hvm-capable systems? Thank you! -- WBR,

I am working with multiboot module "mboot.c32". I have had luck using it to boot NetBSD and the Hurd kernel. The problem with booting the Hurd kernel is apparently connected to the extended syntax passed along to it by grub. Grub passes Hurd kernel approximately 4 files, some of which are modules, and another ten (or so) boot arguments, which correspond to those modules and kernel. The

Hello, Using PATH_MAX is not a good idea: POSIX says that that definition is facultative, in case the system does not impose any limit on path length. Some systems may also set PATH_MAX to a quite high value, and we would hence consume a lot of stack. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi all, It looks like Juergen landed the TextAPI libraries for Mach-O in https://reviews.llvm.org/D53945, and also had several follow-ups, but then it was deleted entirely by r347874. I'm not sure if the entire deletion was intentional, since the commit message only mentions reverting a certain series of patches; CC Hans. In any case, I'm wondering if there are plans to revive it, since

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

An improved Mach-O file type detection for sys::IdentifyFileType() This patch add supports for single architecture mach-o files (the current implementation only support Universal Binary), and solve the signature conflict between java class and Universal Binary magics. Note that this function will always returned dynamic library for Universal Binaries (like the current implementation)

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

When I make a simple test program and call abort() and use LLDB to debug it, it has address-to-line mapping. If I then delete the .o file and run LLDB again, it loses the address-to-line mapping. So there must be DWARF info, or otherwise address-to-line info in the .o file. I'm parsing the MACH-O executable, which has a LC_SYMTAB entry, and one of the entries is the file path of the .o file.

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

On Thu, Jan 20, 2005 at 02:38:39AM -0800, John Cortes wrote: > I tried including the SUIFvm header files and got more errors than I > bargained for. Looks like it hasn't been updated to be portable. I > need some help in getting these suifvm references into the code I'm > writing. While I understand that your current goal is translating LLVM -> SUIF, it seems that

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

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

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

Adding Juergen to the thread. On Fri, Mar 15, 2019, 12:20 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Ping. > > > > Would anyone be opposed to me trying to revive the in-tree Mach-O TAPI > code? > > > > Thanks, > > Shoaib > > > > *From: *Shoaib Meenai <smeenai at fb.com> > *Date: *Wednesday, March 6, 2019 at

Thanks for the response, Rui! On Tue, Jun 5, 2018 at 5:26 PM, Rui Ueyama <ruiu at google.com> wrote: > > Besides the features you pointed out, I think Xcode introduced a new way > of listing dynamic linking symbols, and I believe lld doesn't support that. > .tbd files, is that right? A colleague of mine pointed me to Apple's libtapi open source project [1], maybe I can

> Hey Luke, > > Unfortunately, the 'state of the art' is that llc only really supports > emission of native assembly files (-filetype=asm) which can then be > assembled and linked with your native gas/ld. > > There is some source support for 'object file generation', exposed via > the -filetype=obj flag to llc, but it is not complete, and totally > broken