Forgot…
>tg@fish:~ $ ./a.out
struct baa {
int a;
long long b;
};
#include
#include
int main(void) {
struct baa stct;
#define t(w,s) printf("%s\ts=%u\ta=%u\n", #w, \
(unsigned)sizeof(s), (unsigned)__alignof__(s))
#define o(w,m) printf("%s\ts=%u\ta=%u\to=%u\
On Fri, 15 Nov 2024, Finn Thain wrote:
>On NetBSD/m68k I get,
>
>sizeof(struct baa) == 16
>__alignof__(long long) == 8
>__alignof__(struct baa) == 8
That makes sense.
>> Isn't the alignment of a struct the largest alignment of any of its members?
>
>Sometimes...
I think I have a rough idea why
On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:
> On Sun, Oct 27, 2024 at 7:16 AM Finn Thain wrote:
> > On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> > > Finn Thain dixit:
> > >
> > > >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
> > > >case on my Linux/i686 system. 4 !=
On Thu, 14 Nov 2024, at 22:13, Thorsten Glaser wrote:
> On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:
>
>>If we decide to change alignment, I'd rather change all types to
>>natural alignment, to avoid future nasty surprises.
>
> That was my thought; the question is whether toolchain maintainers
On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:
>On i686 (i.e. gcc -m32 on amd64):
>
>__alignof__(long long) = 8
>
>but
>
>sizeof(struct baa) = 12
>__alignof__(struct baa) = 4
>
>???
>Isn't the alignment of a struct the largest alignment of any of its
>members?
I’d say yes. Probably th
Hi Thorsten,
On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser wrote:
> On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
> >as m68k has supported 32-bit alignment through the "-malign-int"
> >switch for a long time.
>
> That switch constitutes a fundamental ABI change, even if
> the effect is
On Thu, Nov 14, 2024 at 7:07 PM Stan Johnson wrote:
> On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
> >> SysVInit uses a huge set of bash scripts where every action involves
> spawning
> >>> a new shell while systemd does all of that in C. Compiled C code is
> >>> definitely
> >>> fas
Hi Adrian,
On Wed, Nov 13, 2024 at 8:55 PM John Paul Adrian Glaubitz
wrote:
> On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
> > Development isn't driven by memory pressure anymore, so code bloat is a
> > natural consequence.
>
> But we're not really suffering from bloat. On the contra
On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
>> SysVInit uses a huge set of bash scripts where every action involves
spawning
>>> a new shell while systemd does all of that in C. Compiled C code is
>>> definitely
>>> faster on an m68k machine than hundreds of shell scripts.
>>
>> Yes,
On Sun, Oct 27, 2024 at 7:16 AM Finn Thain wrote:
> On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> > Finn Thain dixit:
> >
> > >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
> > >case on my Linux/i686 system. 4 != 8:
> > >
> > >struct baa {
> > >int a;
> > >
On Wed, 13 Nov 2024, Thorsten Glaser wrote:
>
> But, as has been pointed out, if we make the current alignment explicit
> everywhere, the kernel ABI does not have to change¹. And new syscalls,
> ioctls, structs, etc. can just be made with natural alignment in mind (I
> bet most are already an
On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:
>
> > 3) among all 680x0 developers interested in the NetBSD ABI
>
> The alignment issue affects NetBSD as well.
>
My experiments showed that my NetBSD/mac68k system aligns int struct
members like my i686 system does.
On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:
> > Then don't leave it to chance.
>
> What is supposed to mean? Are you implying that I never tried to address
> this?
>
Obviously, it means I'm not interested in your estimation of the chances
of rejection. But you're still trying to t
On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:
> On Mon, 2024-10-28 at 19:40 +1100, Finn Thain wrote:
> > On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> >
> > > What ecosystem? Do you honestly care that any hobbyist cares about
> > > having to reinstall their retro computers?
>
(please keep my debian.org address in the distribution list,
not the mirbsd one, as it has better chance to interact with
other mail providers out there for this… except Googlemail,
which, of course, is no proper mail provider and actively
disrecommended because it fails to collaborate for FOSS wor
On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
> I didn't say that - just supporting Arnd's point that much of the RAM
> constrained old m68k software won't benefit from today's user space.
We're talking about an open source stack here. No one is going to run an
old binary from the 80s
On Wed, 2024-11-13 at 13:48 -0700, Stan Johnson wrote:
> > But we're not really suffering from bloat. On the contrary, both software
> > like systemd or Rust-compiled software actually use less memory, not more.
>
>
> Well, systemd is completely useless on every 68030 and 68040 Mac that I
> own,
On Wed, 2024-11-13 at 20:55 +0100, John Paul Adrian Glaubitz wrote:
> > Sure, you do pretty much all the work on Debian/68k, so you get to decide.
> >
> > If this involves changes at kernel level (syscall parameter alignment?)
> > however, my recommendation would be to rather drop the port than e
On 11/13/24 12:55 PM, John Paul Adrian Glaubitz wrote:
> On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
>> I didn't say that - just supporting Arnd's point that much of the RAM
>> constrained old m68k software won't benefit from today's user space.
>
> We're talking about an open sourc
Adrian,
On 14/11/24 01:54, John Paul Adrian Glaubitz wrote:
On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
Arnd,
On 25/10/24 22:55, Arnd Bergmann wrote:
I also expect that a lot of users (of m68k kernels) are
never going to get the benefits as they are already stuck on
older usersp
On Wed, 2024-11-13 at 10:23 -0500, Mark D wrote:
> Look at it philosophically. One path is to dig in and try to change as
> little as possible to keep the oldest systems working.
>
> The other is to do your best to adapt to keep the greatest relevant to
> modern development.
This isn't the poi
On 11/13/24 7:54 AM, John Paul Adrian Glaubitz wrote:
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.
Thanks, I will then just do it myself with brute force or drop the port.
Adrian
Look at it philosophically.
On Tue, 2024-10-29 at 14:39 +1100, Finn Thain wrote:
> On Tue, 29 Oct 2024, Michael Schmitz wrote:
>
> > On 25/10/24 22:55, Arnd Bergmann wrote:
> >
> > > I also expect that a lot of users (of m68k kernels) are never going to
> > > get the benefits as they are already stuck on older userspace be
On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
> Arnd,
>
> On 25/10/24 22:55, Arnd Bergmann wrote:
> > I also expect that a lot of users (of m68k kernels) are
> > never going to get the benefits as they are already stuck on
> > older userspace because of added bloat in new software
> >
On Mon, 2024-10-28 at 19:49 +1100, Finn Thain wrote:
> > Here is the current top of the list of packages that won't build on m68k
> > because of the 2-byte alignment issue:
> >
> >2814 cargo:m68k
> > 900 ghc:m68k
> > 261 gccgo-14:m68k
> > 241 libqt5core5a:m68k
> > 181 architec
On Mon, 2024-10-28 at 19:44 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > > For Debian, we have superh and i386, out of these. It is entirely
> > > possible that Qt et al. can work with this, but these all have natural
> > > alignment for quantities ≤ 32
On Mon, 2024-10-28 at 19:40 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > What ecosystem? Do you honestly care that any hobbyist cares about
> > having to reinstall their retro computers?
> >
>
> The issue is not just old binaries. You made the same mist
On Mon, 2024-10-28 at 19:29 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > >
> > > That seems to imply that someone requires that those packages are
> > > ported. But without a bug report from such a user, to say the package
> > > is broken or missing, on
On Tue, 29 Oct 2024, Michael Schmitz wrote:
> On 25/10/24 22:55, Arnd Bergmann wrote:
>
> > I also expect that a lot of users (of m68k kernels) are never going to
> > get the benefits as they are already stuck on older userspace because
> > of added bloat in new software releases. I assume yo
Arnd,
On 25/10/24 22:55, Arnd Bergmann wrote:
I also expect that a lot of users (of m68k kernels) are
never going to get the benefits as they are already stuck on
older userspace because of added bloat in new software
releases. I assume you have better understanding than me
of what m68k hardware
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> On Mon, 2024-10-28 at 15:51 +1100, Finn Thain wrote:
>
> > You talk about "applications ... being written". Well, two days ago I
> > mentioned several groups of applications: (1) core packages that
> > accept alignment patches, (2) packa
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> > For Debian, we have superh and i386, out of these. It is entirely
> > possible that Qt et al. can work with this, but these all have natural
> > alignment for quantities ≤ 32 bits.
>
> I'm not aware of any serious issues with alignment
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> What ecosystem? Do you honestly care that any hobbyist cares about
> having to reinstall their retro computers?
>
The issue is not just old binaries. You made the same mistake in your
message to Arnd when you said "we're not allowed to
On Sat, 2024-10-26 at 00:24 +0200, Andreas Schwab wrote:
> On Okt 25 2024, Thorsten Glaser wrote:
>
> > Question is, do we need a kernel change for this at all?
> > Is there anything in the kernel/userland interface that
> > gets affected by this, or do these APIs use sufficient
> > explicit paddi
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> >
> > That seems to imply that someone requires that those packages are
> > ported. But without a bug report from such a user, to say the package
> > is broken or missing, one must question the real requirement.
>
> People have tried th
On Mon, 2024-10-28 at 15:51 +1100, Finn Thain wrote:
> You talk about "applications ... being written". Well, two days ago I
> mentioned several groups of applications: (1) core packages that accept
> alignment patches, (2) packages whose developers shouldn't worry about
> small systems anyway,
On Mon, 2024-10-28 at 04:07 +0100, Thorsten Glaser wrote:
> On Sun, 27 Oct 2024, Arnd Bergmann wrote:
> > On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
>
> > > Right. And I don't think the problem is going to go away. One solution
> > > that is sometimes raised is better tooling. I'm not sure
Hi Arnd,
On Sun, 2024-10-27 at 13:15 +, Arnd Bergmann wrote:
> On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
> > On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> >
> > > Finn Thain dixit:
> > >
> > > > That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
> > > > case on my
On Sun, 2024-10-27 at 03:08 +, Thorsten Glaser wrote:
> > I think that's overstating the case. Alternatives to rust are available
> > and will be for the foreseeable future. Most notably,
>
> That’s not the point. Google, for example, are aggressively funding
> people to throw away perfectly
Hello Arnd,
On Sun, 2024-10-27 at 12:58 +, Arnd Bergmann wrote:
> On Fri, Oct 25, 2024, at 22:24, Andreas Schwab wrote:
> > On Okt 25 2024, Thorsten Glaser wrote:
> >
> > > Question is, do we need a kernel change for this at all?
> > > Is there anything in the kernel/userland interface that
>
On Sun, 2024-10-27 at 17:16 +1100, Finn Thain wrote:
> Right. And I don't think the problem is going to go away. One solution
> that is sometimes raised is better tooling. I'm not sure how that would
> work. Perhaps a better solution would be language changes to allow a
> struct definition to be
On Sun, 2024-10-27 at 14:47 +1100, Finn Thain wrote:
> On Sun, 27 Oct 2024, Thorsten Glaser wrote:
>
> > > https://gcc.gnu.org/wiki/RustFrontEnd
> >
> > That’s assuming it can build the same stuff the same way so it can be
> > used in packaging.
> >
>
> Not an assumption. I simply pointed out
On Sun, 2024-10-27 at 13:49 +1100, Finn Thain wrote:
> I think that's overstating the case. Alternatives to rust are available
> and will be for the foreseeable future. Most notably,
> https://safecpp.org/draft.html
It's not just about Rust:
> https://people.debian.org/~glaubitz/alignment-meme.
On Sun, 2024-10-27 at 00:04 +0200, Thorsten Glaser wrote:
> > That seems to imply that someone requires that those packages are ported.
>
> Yes, we do. Rust especially is killing the entire FOSS ecosystem.
Could we leave out politics out of this discussion, please?
> These all are conditio sine
Hi Geert,
On Sat, 2024-10-26 at 12:46 +0200, Geert Uytterhoeven wrote:
> On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser wrote:
> > Additionally… has anyone done the simple “enable -malign-int
> > in GCC, begin rebuilding stuff, first glibc, then others,
> > see what breaks”? Is there sufficient
On Sat, 2024-10-26 at 18:31 +1100, Finn Thain wrote:
> > The following packages require 32-bit alignment:
> >
> > - mold
> > - LLVM
> > - gccgo
> > - Qt5 (several packages affected)
> > - Qt6 (several packages affected)
> > - OpenJDK (all versions)
> > - Python >= 3.13
> > - Rust
> >
>
> That se
On Fri, 2024-10-25 at 23:38 +0200, Thorsten Glaser wrote:
> On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > as m68k has supported 32-bit alignment through the "-malign-int"
> > switch for a long time.
>
> That switch constitutes a fundamental ABI change, even if
> the effect is limite
On Fri, 2024-10-25 at 17:07 +0200, Andreas Schwab wrote:
> On Okt 25 2024, Arnd Bergmann wrote:
>
> > Doing it without a migration path seems worse to me,
> > as this would mean breaking every single existing
> > installation between two kernels, and making it impossible
> > to bisect other issues
On Mon, 28 Oct 2024, Thorsten Glaser wrote:
> ... You don’t understand the problem: applications are being written
> that require natural alignment for at least 32-bit and smaller
> quantities, some possibly for all quantities even. We need these
> applications to work, and we cannot redesign
On 28/10/24 13:19, Thorsten Glaser wrote:
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want
That would be good in general, yes. I’d personally argue for
using explicit padding
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
>I think it makes sense to go through these anyway and annotate
>them to document and enforce the alignment we actually want
That would be good in general, yes. I’d personally argue for
using explicit padding members (please do NOT use __unused,
rather __
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
>On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
>>Right. And I don't think the problem is going to go away. One solution
>>that is sometimes raised is better tooling. I'm not sure how that would
No. You don’t understand the problem: applications are be
On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
> On Sun, 27 Oct 2024, Thorsten Glaser wrote:
>
>> Finn Thain dixit:
>>
>> >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
>> >case on my Linux/i686 system. 4 != 8:
>> >
>> >struct baa {
>> >int a;
>> >long l
On 26/10/24 09:42, Thorsten Glaser wrote:
On Sat, 26 Oct 2024, Andreas Schwab wrote:
Already basic things like struct stat64 will break.
OK. Then, flag day, I guess.
How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no coïnstallability, rename the
arch
On Fri, Oct 25, 2024, at 22:24, Andreas Schwab wrote:
> On Okt 25 2024, Thorsten Glaser wrote:
>
>> Question is, do we need a kernel change for this at all?
>> Is there anything in the kernel/userland interface that
>> gets affected by this, or do these APIs use sufficient
>> explicit padding? Has
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
> >case on my Linux/i686 system. 4 != 8:
> >
> >struct baa {
> >int a;
> >long long b;
> >} foo;
>
> That struct is just 12 bytes for you t
Finn Thain dixit:
>That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
>case on my Linux/i686 system. 4 != 8:
>
>struct baa {
>int a;
>long long b;
>} foo;
That struct is just 12 bytes for you then?
That’s possible on i386 but almost nowhere else, and has multi
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> >https://gcc.gnu.org/wiki/RustFrontEnd
>
> That’s assuming it can build the same stuff the same way so it can be
> used in packaging.
>
Not an assumption. I simply pointed out an opportunity for collaboration,
because I see the primary problem fa
Finn Thain dixit:
>> >That seems to imply that someone requires that those packages are
>> >ported.
>>
>> Yes, we do. Rust especially is killing the entire FOSS ecosystem.
>>
>> These all are conditio sine qua nōn when it comes to continuing
>> Linux/m68k, as a whole.
>
>I think that's overstat
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> >
> >That seems to imply that someone requires that those packages are
> >ported.
>
> Yes, we do. Rust especially is killing the entire FOSS ecosystem.
>
> These all are conditio sine qua nōn when it comes to continuing
> Linux/m68k, as a whole.
>
On Sat, 26 Oct 2024, Finn Thain wrote:
>> The following packages require 32-bit alignment:
>>
>> - mold
>> - LLVM
>> - gccgo
>> - Qt5 (several packages affected)
>> - Qt6 (several packages affected)
>> - OpenJDK (all versions)
>> - Python >= 3.13
>> - Rust
>
>That seems to imply that someone requi
Hi Thorsten,
On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser wrote:
> Additionally… has anyone done the simple “enable -malign-int
> in GCC, begin rebuilding stuff, first glibc, then others,
> see what breaks”? Is there sufficient effect that we cannot
> incrementally change over?
I guess there
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-10-25 at 20:06 +1100, Finn Thain wrote:
> > On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
> >
> > > the m68k port has reached the point where switching the default
> > > alignment from 16-bit to 32-bit is inevitable a
On Sat, 26 Oct 2024, Andreas Schwab wrote:
>Already basic things like struct stat64 will break.
OK. Then, flag day, I guess.
How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no coïnstallability, rename the
architecture from m68k to… something else, or…?
Bu
On Okt 25 2024, Thorsten Glaser wrote:
> Question is, do we need a kernel change for this at all?
> Is there anything in the kernel/userland interface that
> gets affected by this, or do these APIs use sufficient
> explicit padding? Has anyone looked at this?
Already basic things like struct stat
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>as m68k has supported 32-bit alignment through the "-malign-int"
>switch for a long time.
That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anyt
On Okt 25 2024, Arnd Bergmann wrote:
> Doing it without a migration path seems worse to me,
> as this would mean breaking every single existing
> installation between two kernels, and making it impossible
> to bisect other issues, and breaking the rule #1.
That's why I didn't change the alignment
On Fri, Oct 25, 2024, at 10:10, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-10-25 at 09:55 +, Arnd Bergmann wrote:
>> I think the idea of using the generic syscall ABI (in particular
>> the time64-only variant) makes sense if there is going to be a
>> new ABI, and I can help figure out what
On Fri, Oct 25, 2024, at 06:48, John Paul Adrian Glaubitz wrote:
> Hello,
>
> the m68k port has reached the point where switching the default alignment
> from 16-bit to 32-bit is inevitable as the number of packages affected by
> alignment issues have become too large. It even includes Python 3.13
Hi Arnd,
On Fri, 2024-10-25 at 09:55 +, Arnd Bergmann wrote:
> I think the idea of using the generic syscall ABI (in particular
> the time64-only variant) makes sense if there is going to be a
> new ABI, and I can help figure out what needs to be done in the
> kernel for that.
I don't actuall
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
> the m68k port has reached the point where switching the default
> alignment from 16-bit to 32-bit is inevitable as the number of packages
> affected by alignment issues have become too large. It even includes
> Python 3.13 these days.
>
On Fri, 2024-10-25 at 20:06 +1100, Finn Thain wrote:
> On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>
> > the m68k port has reached the point where switching the default
> > alignment from 16-bit to 32-bit is inevitable as the number of packages
> > affected by alignment issues have bec
72 matches
Mail list logo
