similar to: [PATCH] Re: klibc barfs on m68k syscall interface

Debian: (Closes: #334917) Signed-off-by: Thorsten Glaser <tg at mirbsd.de> --- usr/klibc/arch/m68k/syscall.S | 42 +++++++++++++++++++++++++++++++++------- usr/klibc/arch/m68k/vfork.S | 13 +++-------- 2 files changed, 38 insertions(+), 17 deletions(-) diff --git a/usr/klibc/arch/m68k/syscall.S b/usr/klibc/arch/m68k/syscall.S index 966c92d..f468678 100644 ---

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

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

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

Commit-ID: a7a754c66437d4ab26503cdc183fd9e54a9e84d0 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a7a754c66437d4ab26503cdc183fd9e54a9e84d0 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Thu, 30 Apr 2020 14:06:32 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Thu, 30 Apr 2020 14:08:28 +0100 [klibc] arch: Remove cris port

The parts of klibc specific to the cris architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 84f6a72f42cf41e32daa59871a0b5424572093e4 tree 52bad10c1575f773a71cd4f4ea4b8083631f9d82 parent 1eff7c685b36cd0120694fd4150b32a26168d926 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:18 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

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:

klibc now runs on the CRIS archtitecture. The patch below is against 0.146. Most of the changes are trivial but the new files in libgcc requires some comments. __negdi2.c: The CRIS port fallbacks to C-code for negdi2. The code in __negdi2.c is copied from libgcc2.c but with modified typenames. I would really appreciate if someone could check if it seams sane. crisarith.c: CRIS has no built-in

m68k is the only debian arch still lacking a klibc port... So I started working on this tonight, despite not knowing anything about the m68k. Puzzling out the details, and disassembling things, I've at least got a syscall.c that looks like it might work. I don't really have time to do this bring up, but maybe someone else would like to finish the work. I guess this needs at least,

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

found by Christian T. Steigies <cts@debian.org> usr/include/arch/m68k/klibc/archstat.h:12: error: syntax error before '__dev64' better use __stdev64 defined in klibc/stathelp.h Signed-off-by: maximilian attems <maks@sternwelten.at> diff --git a/usr/include/arch/m68k/klibc/archstat.h b/usr/include/arch/m68k/klibc/archstat.h index 89c0341..dce25f9 100644 ---

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- arch/m68k/kernel/dma.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c index cbc78b4117b5..8cf97cbadc91 100644 --- a/arch/m68k/kernel/dma.c +++

Hi Min! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > Showing the prerequisites to become an experimental target and eventually, > an official target. We're currently struggling on setting up the buildbot > but I believe Adrian (CC-ed) is working on that. So I hope the patches can > be sorted out while waiting for the buildbot. The m68k machine is actually already up and running, I

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

Hello! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > 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. Are there any news on this? The M68k buildbot is ready

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.

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

Binary distributions of R-0.49 for NEXTSTEP (Intel and M68k) are now available on CRAN: http://www.ci.tuwien.ac.at/R/bin/i386-nextstep/R.0.49.I.b.tar.gz http://www.ci.tuwien.ac.at/R/bin/m68k-nextstep/R.0.49.N.b.tar.gz Because NEXTSTEP doesn't support dynamic loading, I've compiled in a number of additional functions (mostly from the user contributed section of CRAN) which I find

I have a few weeks of downtime between jobs coming up and I was considering trying to put together a m68k backend for LLVM. I have some experience with compiler front ends; I've maintained a couple of DSL implementations in the past, but I have relativly little knowledge of code generation. I know that there have been a few attempts in the past, but I cannot find any evidence that they made

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 - is there anything else? Sounds good. I'll file that bug tomorrow. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz :