Hi,
On Mon, 2025-06-23 at 01:13 +0300, Eero Tamminen wrote:
> On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> > To summarize:
> >
> > - the ELF header provides provides the e_ident and e_flags fields which
> > could be
> >used for identifying a Li
that run on both.
OK, but I assume that's not really a relevant usecase.
And since Greg already said that he is not generally rejecting the idea of
switching the default alignment, we should rather discuss what would be
the best way to implement this without causing a lot of headache.
Adria
ry too many ColdFire uses,
> they don't use distributions like debian on them. (I would love to hear from
> anyone who does!).
Thanks a lot for confirming this!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ire. However, since buildroot
builds completely from source, it wouldn't even be a problem to change the
alignment
there as well.
PS: I would like to lead a discussion on how to implement this properly and
not continue to have one why this shouldn't be done as the latter is continuin
(for the stack):
/* ColdFire and fido strongly prefer a 32-bit aligned stack. */
#define PREFERRED_STACK_BOUNDARY \
((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
It's instruction set is also not fully compatible AFAIK.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' :
nstead of just insisting on adhering to a broken ABI that no one
really cares about anymore in the year 2025.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
using GDB_OSABI_LINUX for
the old Linux ABI.
This bug is another example why it was not a good idea to ignore the official
AT&T System V ABI ELF specification as it proves that independent upstream
projects look at the actual official specification when implementing code.
Adrian
--
.''
> unused bits (Hi Apple 24-bit). When using the low bit(s) for tagging,
> you have to make sure the objects you are pointing to are sufficiently
> aligned. BTW, how does LLVM tag pointers to chars?
I don't know. I'm not an expert on the LLVM codebase even though I made some
e
NetBSD organization?
> > > Is this a Rust issue, or an LLVM issue?
> >
> > https://github.com/M680x0/M680x0-mono-repo/issues/10
>
> So you mean it's an LLVM issue.
It's an issue on many projects that use things like tagged pointers etc.
Adrian
--
.''`. J
sible on m68k?
> Is this a Rust issue, or an LLVM issue?
https://github.com/M680x0/M680x0-mono-repo/issues/10
> In case of the latter, how does llvm-mos handle this?
llvm-mos does not build natively the 6502, so this is irrelevant.
Adrian
--
.''`. John Paul Adrian Glaubitz
made for 64-bit time_t[2].
That's not the question to ask though but rather whether the shift to 64-bit
time_t changed the ABI and according to the analysis made at Debian, it did [1].
Adrian
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Geert,
On Mon, 2025-06-16 at 14:29 +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
> wrote:
> > I wrote that message on Friday. Odd that your email client claims it was
> > sent today.
> > Besides that,
glaubitz@panama:~$
> If the existing binaries correctly label themselves has having the
> Linux-specific ABI,
> then this is trivial and there’s no reason to use a note to differentiate
> them.
I don't have a strong preference as both of them are used in the Linux kernel.
Hello Geert,
On Mon, 2025-06-16 at 13:54 +0200, Geert Uytterhoeven wrote:
> On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz
> wrote:
> > On Thu, 2025-06-12 at 08:25 +, Administrator @ R·V·E wrote:
> > > Thanks for your great hard work and efforts to mantai
On Mon, 2025-06-16 at 13:10 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
> > I think an e_flags with a new value like EF_M68K_ABI2 would be more
> > appropriate.
>
> How is it currently used on m68k and does QEMU use it?
> uname -a
Linux suse-laptop 6.15.1-1-default #1 SMP PREEMPT_DYNAMIC Thu Jun 5 14:29:05
UTC 2025 (75961ad) x86_64 x86_64 x86_64 GNU/Linux
glaubitz@suse-laptop:~> readelf -h /bin/bash|grep "OS/ABI"
OS/ABI:UNIX - System V
glaubitz@suse-laptop:~>
A
th 4 bytes alignment.
Adrian
> [1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#ELF_header
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
>
> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
> > > And there will be a problem with binfmt_misc because we can't rely on
> > > the ELF signature to know which qemu-user to run, the one with 2by
ader:
> > > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> >
> > How does binfmt_misc handle the various MIPS ABIs then?
>
> It doesn't and it's a problem.
Very interesting. Is there a bug report for that?
Adrian
--
.''`. John Paul Adrian Glaubit
w which qemu-user to run, the one with 2byte
> > alignment or the one with 4byte alignment?
>
> Exactly.
We could use PT_NOTE [1] for this purpose.
Adrian
> [1] https://github.com/search?q=repo%3Aqemu%2Fqemu%20PT_NOTE&type=code
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
lem with binfmt_misc because we can't rely on
> the ELF signature to know which qemu-user to run, the one with 2byte
> alignment or the one with 4byte alignment?
What about the ELF note [1] that David Brownlee suggested? Can these be used?
Adrian
> [1] https://www.netbsd.org/docs/k
is one of these softwares that know m68k has alignment of
> 2byte. All the structures translated from the m68k chroot to the host
> kernel are with a 2byte alignment.
And yet it works without any problems so far. Please try the Gentoo chroot
yourself.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, 2025-06-16 at 08:33 +0200, Laurent Vivier wrote:
>
> Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
> > On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
> > > A stupid question: is this possible to remove from debian the packets
> > > tha
ing. I'm not here to create a legend. I'm here to work
on a hobbyist project. You are completely blowing this out of proportion.
> So to answer your fine question, Adrian, I continue to engage out of hope
> that you will finally realize that there are better ways to serve the
> c
nment.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
nt.
Adrian
>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
't understand the reference to the NS32008 architecture?!
> In that case adding 2) plus the code to detect and reject new ABI
> binaries on old systems becomes if anything more interesting, and....
> I'm sure we can look forward to more animated discussions on these
> lists...
Yes!
On Sun, 2025-06-15 at 11:42 +1000, Finn Thain wrote:
> On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> >
> > Sure, we can remove Python on m68k. But whether it will still be useful
> > after that remains a different question. I would argue we should rather
&
which include build failures that will be available once
> the quarter is over, but the primary reason packages you might expect to
> be there aren't is simply the speed of our build machines.
Please post them on the port-m68k mailing list once they become available.
Adrian
--
.
used on both should work fine, and one needs to
> review only m68k asm that differs on Linux.
Exactly my point. It works on NetBSD, so I'm not worried about Linux.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ns with 4 bytes alignment.
Why shouldn't this work for Linux?
And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment
without any problems. If you think there are problems with 4 bytes alignment,
I would like to see them reported.
Adrian
--
.''`. John
ng &
> boot-strapping support being much better now...
That's why I want to make a hard cut and not invest months of work when the
userbase consists of just a few people.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ult alignment will fix a plethora of broken packages and
while it
may come with some regressions here and there, I am very confident it's the
right
way to go.
The Gentoo developers are pursuing this path as well meaning that there won't be
any distributions with 2 bytes alignment
On Fri, 2025-06-13 at 14:51 +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> > So you change the default alignment, bump all so-versions in userspace,
> > but keep the kernel-userspace ABI the same by adding explicit alignment
run old binaries on a retro-computing
architecture
is is so important for some people that they think it justifies making my life
miserable.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
dress this problem. Rather, it's just making me feel
worse and questioning
my life decisions.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
nge would break the "Linux ABI" when the Linux
ABI is currently broken and doesn't even allow for Python to be built without
further modifications.
What is your suggested alternative? Do you expect me to patch broken packages
into all eternity? If keeping 2 bytes alignment ABI is so import
68k Debian is too heavy to boot in reasonable time on machines
> that Hatari emulates, due to missing crypto acceleration, but IMHO also
> unnecessary for kernel ABI change discussions.)
Last time I booted Debian/m68k on my Amiga 68060 it booted fine. It took
a few minutes but that
appreciate these efforts and seem to think that this all comes at zero costs.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, 2025-06-12 at 18:19 +1000, Finn Thain wrote:
> On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> > On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > >
> > > Fixing pthreads would probably go a long way. That's where we lost
code that is slower and
working is better than code that does not work at all.
Both you and Finn still seem to miss the point that the current 2 bytes
alignment
path is a dead end and neither you nor Finn have made any substantial
contributions
to keep this path alive.
If you want to keep t
ealistic counter-proposals when they have no clue
how distributions
are maintained and how tedious it is to spin your own distribution.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, 2025-06-12 at 11:54 +1000, Finn Thain wrote:
> On Wed, 11 Jun 2025, John Paul Adrian Glaubitz wrote:
>
> >
> > I'm not sure what you are trying to say here. The fact that your
> > computer is too slow for modern Linux distributions is unrelated to
ady working on it. If you prefer maintaining a Linux port with
2 bytes alignment, you are free to do so. But please don't expect me to waste
my time on it.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, 2025-06-10 at 21:04 -0600, Stan Johnson wrote:
> On 6/10/25 5:26 AM, John Paul Adrian Glaubitz wrote:
> > ...
> > On m68k, on the other hand, the user base is so small and insignificant
> > that the costs for introducing the change are negligible and the profits
>
t(2) system call from 1994 using the a.out ABI.
Thanks a lot for answering this question. I was actually wondering whether
old a.out binaries would still run on current versions of NetBSD despite
the different alignment.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Deve
es in the Debian
> archive which actually need porting.
Finn, you seriously have to be kidding me. I have created a wiki page with
all the packages in question and I have posted a link to that page multiple
times.
See: https://wiki.debian.org/M68k/Alignment
Are you deliberately ignoring that?
at both Debian and Gentoo
get to have a word in this discussion, don't they?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi,
On Sat, 2025-06-07 at 13:32 +0200, John Paul Adrian Glaubitz wrote:
> The gcc maintainer will certainly know better whether all of these are
> needed to fix the build and consequently avoid other packages from being
> miscompiled or failing to build.
I was not able to tune gcc-14
On Sat, 2025-06-07 at 17:20 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>
> > On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
> > > On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> > >
> > > > you cannot ch
On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>
> > you cannot change the ABI because that would change the ABI.
>
> That's the fundamental property of an ABI.
Not if the ABI was made-up by yourself ;-).
A
On Sat, 2025-06-07 at 16:38 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>
> > On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
> > > On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> > >
> > > > Who is "
he appropriate moniker for
that.
Providing users with options is usually the best way to deal with conflicts.
Adrian
> [1] https://lore.kernel.org/all/87y3i442w1@linux-m68k.org/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
using ELF binaries uses 4
bytes
alignment. If that isn't a representation of the official ABI then I don't know
what is.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>
> > Who is "we"? The official(!) ABI says that pointers are supposed to be
> > aligned
> > with 4 bytes, not 2 bytes.
>
> No, that is wrong.
from being
miscompiled or failing to build.
Thanks,
Adrian
> [1]
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a
> [2] https://buildd.debian.org/status/package.php?p=gcc-15&suite=experimental
--
.''`. John Paul Adrian Glaubitz
:
a value judgement you're free to make regarding your systems.
> It's easy to find fault in other peoples' systems but it's also pointless.
> It won't get us closer to a consensus that will hold for another 30 years.
I'm not seeing how violating the official ABI wa
ytes alignment can continue to do
so.
The same would apply for gcc and glibc. Both can offer a configure option to set
the default alignment to 4 bytes. This way everyone who wants to continue using
2 bytes alignment can continue to do so without further ado.
And anyone else who wants to
it. They even broke the ABI on a production architecture (s390) back
in 2014 [1] and apparently we were all able to move on after this.
Adrian
> [1] https://lwn.net/Articles/605607/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
xing the offsets like that, as it depends on
> the BIGGEST_ALIGNMENT value...
Yes, please send a patch. I don't expect it to be accepted immediately, but
it will help us spur a discussion on the necessary changes in the kernel.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :&
The source code in arch/m68k/kernel/signal.c contains a lot of hard-wired
offsets
which will probably have to be adjusted.
You can try changing 0x12 to 0x14 and see if that fixes it.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, 2025-06-02 at 21:41 +0200, Andreas Schwab wrote:
> On Jun 02 2025, John Paul Adrian Glaubitz wrote:
>
> > To me both statements seem to contradict each other.
>
> How? They comment two different things.
But it's DEFAULT_PCC_STRUCT_RETURN in both cases, no?
A
On Mon, 2025-06-02 at 19:44 +0200, Andreas Schwab wrote:
> On Jun 02 2025, John Paul Adrian Glaubitz wrote:
>
> > Both NetBSD and Linux return structs differently, yet the comments in the
> > source code claim their way is according to the m68k SVR4 specification.
>
>
On Mon, 2025-06-02 at 17:34 +0200, Andreas Schwab wrote:
> On Jun 01 2025, John Paul Adrian Glaubitz wrote:
>
> > I was talking about the comments, not the code since NetBSD and Linux
> > disagree on what the SVR4 ABI claims.
>
> In which way?
Both NetBSD and Linux re
On Sun, 2025-06-01 at 19:44 -0600, Jeff Law wrote:
>
> On 6/1/25 8:21 AM, John Paul Adrian Glaubitz wrote:
>
> >
> > And what about the value for STACK_BOUNDARY? It seems to be 16 for many
> > Linux targets while it's 32 for NetBSD. Is there a reason why i
On Wed, 2025-05-28 at 18:10 +0200, Andreas Schwab wrote:
> On Mai 28 2025, John Paul Adrian Glaubitz wrote:
>
> > Shouldn't the #undef in linux.h undefine DEFAULT_PCC_STRUCT_RETURN and not
> > PCC_STATIC_STRUCT_RETURN?
>
> No, they are separate target options. P
ot;.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Jason,
On Mon, 2025-05-26 at 11:25 -0700, Jason Thorpe wrote:
> > On May 26, 2025, at 8:05 AM, John Paul Adrian Glaubitz
> > wrote:
> >
> > Now I'm wondering whether why some types on NetBSD such as double have 8
> > bytes
> > alignment on a 32-b
in BIGGEST_ALIGNMENT. That
> is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless
> __ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
> BIGGEST_ALIGNMENT should be 16.
The alignment is specified in bits here, not bytes. Hence a BIGGEST_ALIGNMENT
of 64 means 8 bytes, no
al codepath on NetBSD to deal with the
largest possible alignment to be 8 bytes so that the error above does not
occur?
Or could it just be a result of the ABI mismatch because glibc needs to be
patched as well?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian D
Hello Eero,
> On May 21, 2025, at 4:16 PM, Eero Tamminen wrote:
>
> So to start, here are the things that are, and are not, relevant for me _on
> m68k_. I.e. _personal_ opinions. First some general principles, and then few
> examples.
>
>
> Relevant
>
>
> Base system, compilers, i
o gets to make the call about whether or not the change is made?
It should be the people who maintain the distribution.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
based distro, so ideally we need a way for users to migrate their
> existing systems.
Okay, valid point. I wasn't thinking about time64_t at this point but just
-malign-int.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
s alignment:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/10.0_2024Q3/All/
So, I think we're safe in this regard. There are certainly going to be a few
cases
where packages may need to be patched. But I would assume these to be rather
rare.
Adrian
--
.''`. John P
On Tue, 2025-05-20 at 19:46 +1000, Finn Thain wrote:
> On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:
>
> > The fact is that software is moving forward
>
> Right. That's why we now have "Qt for MCUs". The Qt developers aren't
> trying to
h to 4 bytes
> > alignment.
> >
>
> Other language runtimes work fine on the m68k ABI. Why is Rust special?
You mean other languages such as JavaScript, Go, Java, Python and WebKit?
No, they don't work fine on m68k.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :
> >
> > Gotcha.
> >
>
> I assumed the bug may exist, but when I asked about it, you evaded the
> question.
I have created a wiki page for this exact matter:
https://wiki.debian.org/M68k/Alignment
I have posted the link so many times that I don't believe you when yo
On Tue, 2025-05-20 at 19:55 +1000, Finn Thain wrote:
> On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:
>
> > > As for gccgo, has that ever worked on m68k?
> >
> > Yes.
> >
>
> Why is an ABI change needed to get it to work again?
Because software ch
y not.
> Grepping for __mc68000__ may find some.
Well, we can just fix them on the go. If I see Debian packages FTBFS with 4
bytes
alignment, I can just fix them. So far I have not run into any package that did
not build with 4 bytes alignment but plenty that built with it.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, 2025-05-20 at 11:58 +0200, Geert Uytterhoeven wrote:
> On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz
> wrote:
> > And I also don't understand why this is even an issue. If someone insists
> > on using 2 bytes alignment, just stick to your old chroot.
stall their systems? Does this really justify
carrying
patches for many other packages?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ot to use Rust? Tell them not to use
Go?
I don't get it.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, 2025-05-20 at 07:59 +1000, Finn Thain wrote:
> On Mon, 19 May 2025, John Paul Adrian Glaubitz wrote:
>
> >
> > My argument is that Linux/m68k is a pure hobbyist project and anyone
> > involved can deal with the changes coming from the alignment change.
> &g
On Mon, 2025-05-19 at 10:03 +0200, Andreas Schwab wrote:
> On Mai 19 2025, John Paul Adrian Glaubitz wrote:
>
> > Good idea. I will do that. My assumption is that on Linux, GCC developers
> > actually just forgot to switch alignment from 2 to 4 bytes with the switch
> &
On Mon, 2025-05-19 at 10:14 +0200, Florian Weimer wrote:
> * John Paul Adrian Glaubitz via Libc-help:
>
> > I was just looking at the necessary changes to switch m68k to 32-bit
> > alignment
> > and I'm not sure we need to do anything about glibc. I am documenting
Hi Geert,
On Mon, 2025-05-19 at 10:25 +0200, Geert Uytterhoeven wrote:
> On Mon, 19 May 2025 at 10:18, John Paul Adrian Glaubitz
> wrote:
> > On Mon, 2025-05-19 at 10:03 +0200, Andreas Schwab wrote:
> > > On Mai 19 2025, John Paul Adrian Glaubitz wrote:
> > >
>
more about
> the default alignment on other (legacy UNIX) OSes supporting m68k...
Good idea. I will do that. My assumption is that on Linux, GCC developers
actually just forgot to switch alignment from 2 to 4 bytes with the switch
to ELF unlike NetBSD.
Adrian
--
.''`. John Paul Adri
pecified by the AT&T ABI.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
NMENT from 16 to 64 similar to NetBSD/ELF in GCC
should be enough, shouldn't it?
Adrian
> [1] https://wiki.debian.org/M68k/Alignment
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
alignof(long) 8
> alignof(long long) 8
Is alignof() supported in ancient versions of GCC and the Sun compiler?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
th Amiga Unix 2.1 then since it ships GCC 1.40.5.
;-)
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Geert,
On Wed, 2025-05-14 at 08:55 +0200, John Paul Adrian Glaubitz wrote:
> On Tue, 2025-05-13 at 22:08 +0200, John Paul Adrian Glaubitz wrote:
> > There is a guide available which explains how to install AMIX on WinUAE:
> >
> > https://www.amigaunix.com/doku.php/instal
Hi Geert,
On Tue, 2025-05-13 at 22:08 +0200, John Paul Adrian Glaubitz wrote:
> There is a guide available which explains how to install AMIX on WinUAE:
>
> https://www.amigaunix.com/doku.php/installation
>
> https://oldosplayground.blogspot.com/2018/01/amiga-unix-amix-21-in
t; Dunno, probably ELF, as ELF originated on SVR4.
There is a guide available which explains how to install AMIX on WinUAE:
https://www.amigaunix.com/doku.php/installation
https://oldosplayground.blogspot.com/2018/01/amiga-unix-amix-21-installation.html
I will try that later this week. I'
Hi Geert,
On Tue, 2025-05-13 at 09:55 +0200, Geert Uytterhoeven wrote:
> On Mon, 12 May 2025 at 19:01, John Paul Adrian Glaubitz
> wrote:
> > Well, the official SysV ELF ABI by AT&T uses 4 byte alignment, so I would
> > expect
> > any *nix flavor which adheres to t
&T uses 4 byte alignment, so I would expect
any *nix flavor which adheres to the official specification to use 4 byte
alignment.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ebian.org/M68k/Alignment
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ld logs can also be downloaded with the getbuildlog utility
from the devscripts package. See the instructions at the top of every build
log shown on buildd.debian.org.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ers. You will have to talk to the FTP admins for that. Aurelien Jarno
should be able to help you.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Geert,
On Sun, 2025-03-09 at 11:43 +0100, Geert Uytterhoeven wrote:
> On Sun, 9 Mar 2025 at 11:38, John Paul Adrian Glaubitz
> wrote:
> > I have started a page on the Debian wiki for discussing the alignment issue:
> >
> > => https://wiki.debian.org/M68k/Alignme
1 - 100 of 1350 matches
Mail list logo