similar to: [WIP] klibc for m68k

The parts of klibc specific to the m68k architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit bc9b363b31d301ab94c115cccc2e079c0d318498 tree db9cf277429e2722b8c51f68897991f0759b1d02 parent 7ba219f9bcddda38ddc9010b54fd10431292f744 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:29 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Here's an assortment of build and run-time fixes for various architectures that we've applied in Debian. Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at:

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

found by Christian T. Steigies <cts@debian.org> usr/klibc/arch/m68k/crt0.o: In function `_start': usr/klibc/arch/m68k/crt0.S:(.text+0xe): undefined reference to `___libc_init' too many '_'. never seen jbsr, converted that to jsr. Signed-off-by: maximilian attems <maks@sternwelten.at> diff --git a/usr/klibc/arch/m68k/crt0.S b/usr/klibc/arch/m68k/crt0.S index

Hi All, Just a quick update on the Motorola 6800 backend: Based on the feedback, "M68k" (with lowercase "k") will now be the canonical target name and "m68k" be the target triple name. I've updated all the patches under review to reflect this change. I'm also asking for everyone's help to review all the patches. /* Target independent changes */ 1.

tag 334917 = patch thanks Hi, I?ve fixed the m68k syscall of klibc and made it able to use six-argument syscalls like mmap2. However, I could not yet fully test it (only mostly; opendir() specifically fails) due to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 @m68k porters: Please have a look at the gcc bug as well. @klibc: Please apply the patch, it?s better than what we have, and

As well as the actual patch reviews, has there been official approval that the M68k experimental backend can be added to trunk? I guess we need a "Backend: M68k" bugzilla component - is there anything else? On 13/11/2020 22:41, John Paul Adrian Glaubitz via llvm-dev wrote: > Hello! > > On 11/3/20 6:10 PM, Min-Yih Hsu wrote: >> Just a quick update on the Motorola 6800

Hi All, We would like to contribute our supports for Motorola 68000 series CPU (also known as M68k or M680x0) into LLVM. And we want to hear feedbacks from you Here is some background for M68k: Motorola 68000 series CPU was one of the most popular CPUs used by personal computers in the ‘80, including some of the earliest Apple Macintosh. Fast-forwarding to modern days, M68k is still popular

Implement "pid_t vfork(void)" for parisc. Signed-off-by: Kyle McMartin <kyle at parisc-linux.org> --- Ugh. vfork() me harder. Kbuild | 2 +- vfork.S | 31 +++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/usr/klibc/arch/parisc/Kbuild b/usr/klibc/arch/parisc/Kbuild index d57a873..57ca5c2 100644 --- a/usr/klibc/arch/parisc/Kbuild

Hello David! On 11/16/20 11:30 AM, David Chisnall via llvm-dev wrote: > Generally, the bar for being in-tree is fairly low, the bar to being removed > from the experimental-back-ends list is much higher. An experimental back end > is not built by default and is not in any of the binary releases. > > Experimental back ends provide a probation period for the maintainer community.

Hi. I am searching for hints, documents, or a discussion for how to properly model registers. As an experiment to learn llvm I am trying to do a M68k backend by following and modifying the Cpu0 tutorial by Chem Chung-Shu and Anoushe Jamshidi. The M68k registers are 32bit and comes in two classes data (d0-d7) and address (a0-a7). Similar to X86 target a subset of the registers can be accessed

On Tue, 2022-02-01 at 16:23 +0000, Thorsten Glaser wrote: > retitle 925358 qemu-user-static: mis-emulates something to do with process/signal handling (m68k, s390x, ?) > affects 925358 klibc-dev > thanks > > This still happens. (And retitling because I almost filed a bug > against klibc again? oops?) > > Look for ?mtest-external? (second occurrence) in: >

On Debian/m68k, with latest klibc, I get this warning? /usr/bin/m68k-linux-gnu-ld: warning: /usr/lib/klibc/lib/crt0.o: requires executable stack (because the .note.GNU-stack section is executable) ? trying to link an executable with klcc. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert? wer konnte ahnen, da? SIE

On PA-RISC machines running in 64-bit mode, uname -m returns `parisc64' instead of `parisc.' Thus, we must sed this to match like a few other platforms. From: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> diff --git a/Makefile b/Makefile index 2b057b8..16a026d 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ include

On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote: > On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > As a result of backporting a bugfix, virtio_net started passing void * > > to page_address, assuming that it will get silently converted to struct > > page *. But this does not happen on architectures where page_address

On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote: > On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > As a result of backporting a bugfix, virtio_net started passing void * > > to page_address, assuming that it will get silently converted to struct > > page *. But this does not happen on architectures where page_address

On Sun, Nov 15, 2020 at 1:27 PM John Paul Adrian Glaubitz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 11/15/20 9:33 PM, Simon Pilgrim via llvm-dev wrote: > > As well as the actual patch reviews, has there been official approval that the > > M68k experimental backend can be added to trunk? I guess we need a > > "Backend: M68k" bugzilla component -

Hello friends, A couple years back I’ve started a M68K codegen port of LLVM, and then suspended it for the lack of free time. Now I finally got some time and willing to continue working on it. To keep up with LLVM changes I'd like to merge it upstream. There is already patch for it: https://reviews.llvm.org/D50314 <https://reviews.llvm.org/D50314>, but then I was reminded that adding

Its awesome to see so much progress on this! A very minor question - why is it called M680x0 and not M68K given that's what the target arch/triple is and how its usually referred to? Sorry for the bikeshedding.... Simon. On 30/09/2020 21:14, Min-Yih Hsu via llvm-dev wrote: > Hi All, > > I've composed a draft roadmap for this new target. I've decided to try >