similar to: ISO C99 inline, again

Hello, how would I go porting llvm-gcc-4.2 to an “unknown” platform, i.e. MirBSD? For regular gcc, I’d have to add stuff to gcc/gcc/config/ and patch quite some configure scripts, but seeing that llvm-gcc uses LLVM for target specific stuff, how much of this still applies? cpp defines and startup files at the least, probably, for the com- piler driver… Which dependencies does llvm-gcc-4.2 have,

Hi, after changing mksh to no longer use mkstemp, I decided to try and build mksh-static with klcc on most platforms, in Debian. Here are the results by Debian architecture: alpha (4) fails amd64 works armel works armhf (3) fails i386 works ia64 works m68k (1) workaround mips works mipsel works powerpc (2) fails ppc64 works (!) s390 works s390x works sparc works Architectures not listed either

llvm-gcc bits are but a small part of it. You need to add a new target to llvm. Please read llvm documentation and llvmdev archieve for more information. Evan On Nov 2, 2008, at 7:38 AM, Thorsten Glaser wrote: > Hello, > > how would I go porting llvm-gcc-4.2 to an “unknown” platform, i.e. > MirBSD? For regular gcc, I’d have to add stuff to gcc/gcc/config/ > and patch quite

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

SIGSUSPEND(2) Linux Programmer's Manual SIGSUSPEND(2) NAME sigsuspend - wait for a signal SYNOPSIS #include <signal.h> int sigsuspend(const sigset_t *mask); ? and ? SIGSUSPEND(2) BSD Programmer's Manual SIGSUSPEND(2) NAME sigsuspend - atomically release blocked signals and wait for interrupt SYNOPSIS

See http://gcc.gnu.org/gcc-4.3/porting_to.html for details. Signed-off-by: Jon Ringle <jon at ringle.org> --- usr/include/klibc/compiler.h | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/usr/include/klibc/compiler.h b/usr/include/klibc/compiler.h index 816a4ee..e0da37e 100644 --- a/usr/include/klibc/compiler.h +++ b/usr/include/klibc/compiler.h @@ -24,7 +24,11

Steve Capper dixit: >> Do we need the fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregparm=3 is used by the i386 target. bye, //mirabilos

Hi, is there a DD-accessible porterbox somewhere (slow would be ok, as this is smallish software) with an up-to-date sid (enough to install the recently-built libklibc-dev 2.0~rc5-1 and all other B-D of mksh 40.9.20120518-1, as well as strace and gdb-minimal)? Similarily to http://www.zytor.com/pipermail/klibc/2012-May/003229.html I found klibc-compiled programmes on Alpha to fail (SIGSEGV

Hi *, I was just debugging why TFTP booting did not work any more on a system that had pxelinux.0 was updated. ?Since version 5.00, support for 16-bit COMBOOT modules has been dropped, and c32 modules switched from the COM32 object format to ELF.? Ugh. Well, updating the *.c32 files was enough to make the Linux discless thingy work again. BUT! The MirBSD bootloader actually took advantage of

Hi sh4 porters, I?ve just fixed a regression of klibc to build from source on sh4 using the sumotsu.debian.net porterbox (thanks for making one available) and found a problem with your archi- tecture: all binaries built with klibc (shared and static) get a SIGILL (illegal instruction). I suspect that different CFLAGS are needed. Please, someone, have a look at it; a release of klibc 2.0 upstream

On Fri, 5 Dec 2014, Gene Cumm wrote: > >> mostly in C and be BIOS-only) or making the MirOS kernel act like > >> either an MBOOT kernel or a Linux kernel (for their boot protocols), The MirBSD _bootloader_ (not kernel) can act as a Multiboot kernel. It can then use disc access (not PXE), or you can pass it the ?real? kernel, but also e.g. configuration files, as Multiboot

On Wed, Apr 13, 2016 at 7:24 PM, Thorsten Glaser <tg at mirbsd.de> wrote: > Denis Bychkov dixit: > >>This is a klibc port to x32 architecture. I tried to reuse as many >>existing files as possible, hence, a >>script making symlinks to x86-64 files. I was running this on Debian >>for about six months and hopefully, >>found any close to surface bugs. Of

Hi, number three, where I first thought it was a GCC bug but is apparently bad code in klibc. Submitted with permission: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533#c6 Patch attached again (sorry) not just because that is easier with my mail system but also to keep original author intact. bye, //mirabilos -- > emacs als auch vi zum Kotzen finde (joe rules) und pine f?r den einzig >

tags 516774 = patch tags 516294 = upstream thanks Hi! Please find attached a diff closing #516774 by adding mkstemp(3), again with a minimalistic pseudo-arc4random(3) behind it. I?ve revisited the code. An mkstemp testsuite from the ?net shows it works, except for not caring how many ?X?en are in the template. Addressing #516294, it allows compiling and linking an mksh from today?s CVS against

On Tue, 2 Dec 2014, H. Peter Anvin wrote: > This is the default unless the "quiet" option is set. Hmm. tglaser at luna:/srv/tftp $ fgrep -ri quiet . Binary file ./hdt.c32 matches Binary file ./ldlinux.c32 matches Binary file ./vmlinuz matches Binary file ./linux.c32 matches Binary file ./debian-installer/jessie/amd64/linux matches Binary file ./debian-installer/jessie/i386/linux

Hi, no mailing list for powerpcspe? What?s the progress of your architectures? I don?t see much happening on debian-ports.org, and taking your architectures off that infrastructure hurts others (I?ve ?revived? m68k and kept it running on d-p.o which helps a bit). Anyway: a new klibc (2.0~rc5-1) has been uploaded, and an mksh companion version (40.9.20120518-1) depending on it and trying to use

Hi, after a year, I decided to hack on klibc again. I?ve reworked both the patch to add mkstemp(), discussing to use AT_RANDOM as cheap entropy source on IRC (if there will ever be another entropy consumer, I can quickly write a minimal arc4random() seeded from it, as it has only 16 octets), capable of making a working mksh (static and shared) on amd64/xen, and the m68k support code, leading to

This uses time, ASLR and pid for randomisation. (Closes: #516774) Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- usr/include/stdlib.h | 2 + usr/klibc/Kbuild | 2 +- usr/klibc/mkstemp.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 96 insertions(+), 1 deletions(-) create mode 100644 usr/klibc/mkstemp.c diff --git a/usr/include/stdlib.h

On Fri, 5 Dec 2014, Ady wrote: > A link to original documentation is very useful. Links to manpages > and/or to CVSweb are both fine. Some users might prefer the man page > (which might or might not be up-to-date and/or enough), and the CVSweb > content might be valuable for others. OK, sure. The sources are mostly in https://www.mirbsd.org/cvs.cgi/src/sys/arch/i386/stand/ (boot/

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses