Geert Uytterhoeven dixit:
>Probably you know this, but it may also depend on your version of gcc.
For TLS on m68k, this would be gcc-4.5 (and up)…
so much is known. With lesser versions, TLS, and
probably the syscall in question (?, I don’t really
know Linux well) won’t work anyway, so this shoul
On Mon, Jun 7, 2010 at 23:33, Andreas Schwab wrote:
> Richard Zidlicky writes:
>
>> why does not a simple "__attribute__ ((aligned (4)))" work?
>
> It does, more or less. I still get unexplained deadlocks and failures
> in some test cases.
Probably you know this, but it may also depend on your
Richard Zidlicky writes:
> why does not a simple "__attribute__ ((aligned (4)))" work?
It does, more or less. I still get unexplained deadlocks and failures
in some test cases.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 82
On Sun, Jun 06, 2010 at 08:51:05PM +0200, Geert Uytterhoeven wrote:
> On Sun, Jun 6, 2010 at 20:37, Brad Boyer wrote:
> > On Sun, Jun 06, 2010 at 10:42:40AM +0200, Andreas Schwab wrote:
> >> Brad Boyer writes:
> >>
> >> > I may be missing something obvious, but why don't we just change the
> >> >
On Sun, Jun 06, 2010 at 11:52:00AM -0700, Brad Boyer wrote:
> Is there a document somewhere on how all of this works, or is it
> just the comments scattered about all the code? The man page for
> the system call isn't really enough to explain the implementation.
I wouldn't normally respond to my o
On Sun, Jun 06, 2010 at 10:48:25AM +0200, Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>
> > Don't know if there are other places that make assumptions about
> > __alignof__(u32) == sizeof(u32).
>
> See get_futex_key_refs.
OK. I see now that the code uses the lowest 2 bits for other purpo
On Sun, Jun 6, 2010 at 20:37, Brad Boyer wrote:
> On Sun, Jun 06, 2010 at 10:42:40AM +0200, Andreas Schwab wrote:
>> Brad Boyer writes:
>>
>> > I may be missing something obvious, but why don't we just change the
>> > kernel to allow 2-byte alignment for m68k? The comment in futex.c
>> > just say
On Sun, Jun 06, 2010 at 10:42:40AM +0200, Andreas Schwab wrote:
> Brad Boyer writes:
>
> > I may be missing something obvious, but why don't we just change the
> > kernel to allow 2-byte alignment for m68k? The comment in futex.c
> > just says "natural" alignment but is then hard-coded for sizeof
Geert Uytterhoeven writes:
> Don't know if there are other places that make assumptions about
> __alignof__(u32) == sizeof(u32).
See get_futex_key_refs.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for some
Brad Boyer writes:
> I may be missing something obvious, but why don't we just change the
> kernel to allow 2-byte alignment for m68k? The comment in futex.c
> just says "natural" alignment but is then hard-coded for sizeof(u32).
Natural alignment *is* sizeof.
Andreas.
--
Andreas Schwab, sch.
On Sun, Jun 6, 2010 at 05:49, Brad Boyer wrote:
> On Thu, Jun 03, 2010 at 06:12:29PM +0200, Andreas Schwab wrote:
>> It is basically working quite well. Unfortunately there is a big
>> problem which becomes apparent when running the libstdc++ testsuite: the
>> m68k compiler only guarantees a maxi
On Thu, Jun 03, 2010 at 06:12:29PM +0200, Andreas Schwab wrote:
> It is basically working quite well. Unfortunately there is a big
> problem which becomes apparent when running the libstdc++ testsuite: the
> m68k compiler only guarantees a maximum alignment of 2 bytes, but the
> futex syscall requ
Richard Zidlicky writes:
> so the problem is reduced to alignment on stack and alignment in structs?
The problem is alignment.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different
On Sat, Jun 05, 2010 at 11:21:42AM +0200, Andreas Schwab wrote:
> Richard Zidlicky writes:
>
> > As I see it the stack-allocated futex could be automagicaly aligned when
> > pushed as
> > argument to a function
>
> Futexes are indexed by address. You cannot move them around.
so the problem is
Richard Zidlicky writes:
> As I see it the stack-allocated futex could be automagicaly aligned when
> pushed as
> argument to a function
Futexes are indexed by address. You cannot move them around.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1
Geert Uytterhoeven writes:
> IIRC, on Coldfire the stack is always 4-byte aligned.
m68k-linux also defines PREFERRED_STACK_BOUNDARY == 32, so there is hope
that it actually works.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B
On Sat, Jun 05, 2010 at 12:21:47PM +1000, Finn Thain wrote:
>
> On Sat, 5 Jun 2010, Richard Zidlicky wrote:
>
> > I am not sure what happens if the futex is inside a "misaligned struct"
> > - would that be handled with an attribute of the futex?
>
> Is this problem confined to m68k? (All archit
On Sat, Jun 05, 2010 at 09:19:51AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jun 5, 2010 at 00:52, Richard Zidlicky wrote:
> > On Fri, Jun 04, 2010 at 10:57:50PM +0200, Geert Uytterhoeven wrote:
> > this is the hardware behaviour but the compiler is free to use more
> > alignment
> > and it d
On Sat, Jun 5, 2010 at 04:21, Finn Thain wrote:
> On Sat, 5 Jun 2010, Richard Zidlicky wrote:
>> I am not sure what happens if the futex is inside a "misaligned struct"
>> - would that be handled with an attribute of the futex?
>
> Is this problem confined to m68k? (All architectures seem to be su
On Sat, Jun 5, 2010 at 00:52, Richard Zidlicky wrote:
> On Fri, Jun 04, 2010 at 10:57:50PM +0200, Geert Uytterhoeven wrote:
>> On Fri, Jun 4, 2010 at 21:15, Thorsten Glaser wrote:
>> > Andreas Schwab dixit:
>> >
>> >>One cost is ABI breakage.
>> >
>> > Hrm, that is true. But then: is that syscall
On Sat, 5 Jun 2010, Richard Zidlicky wrote:
> I am not sure what happens if the futex is inside a "misaligned struct"
> - would that be handled with an attribute of the futex?
Is this problem confined to m68k? (All architectures seem to be subject to
the same rule for futex offsets.)
Finn
>
On Fri, Jun 04, 2010 at 10:57:50PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 4, 2010 at 21:15, Thorsten Glaser wrote:
> > Andreas Schwab dixit:
> >
> >>One cost is ABI breakage.
> >
> > Hrm, that is true. But then: is that syscall/structure used already?
> > I think I get an idea of the troub
Geert Uytterhoeven dixit:
>In the past, there's been discussions about changing the alignment of
>32-bit quantities
>to 4 bytes (as on most other architectures) and reserving a register for TLS
>at the same time, as both break the ABI.
Ah, ok, sounds possible then. So, the question is whether it
On Fri, Jun 4, 2010 at 21:15, Thorsten Glaser wrote:
> Andreas Schwab dixit:
>
>>One cost is ABI breakage.
>
> Hrm, that is true. But then: is that syscall/structure used already?
> I think I get an idea of the trouble though…
>
> On the other hand, changing gcc’s default alignment may break
> the
Andreas Schwab dixit:
>One cost is ABI breakage.
Hrm, that is true. But then: is that syscall/structure used already?
I think I get an idea of the trouble though…
On the other hand, changing gcc’s default alignment may break
the ABI as well, no?
>Also, I'm not yet convinced this works in all
>s
Finn Thain writes:
> When I asked the question, I figured that Andreas would have simply added
> the attribute if there was no cost to doing so...
One cost is ABI breakage. Also, I'm not yet convinced this works in all
situations, like for locks allocated on stack.
Andreas.
--
Andreas Schwa
On Fri, 4 Jun 2010, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> >Better to adopt the 4 byte alignment rather than relax the requirement?
> >Or
>
> Why? I mean, you can force alignment where it?s needed, at least in gcc
> (and clang and pcc and and and?) so there?s no need to waste memory,
Finn Thain dixit:
>Better to adopt the 4 byte alignment rather than relax the requirement? Or
Why? I mean, you can force alignment where it’s needed, at least
in gcc (and clang and pcc and and and…) so there’s no need to
waste memory, especially considering the target platform. See my
other mail
On Thu, 3 Jun 2010, Andreas Schwab wrote:
> Wouter Verhelst writes:
>
> > Does anyone know what the status of this support is in libc?
>
> It is basically working quite well. Unfortunately there is a big
> problem which becomes apparent when running the libstdc++ testsuite: the
> m68k compi
Andreas Schwab dixit:
>m68k compiler only guarantees a maximum alignment of 2 bytes, but the
>futex syscall requires 4 byte alignment. So if your pthread mutex is
>not aligned on a 4 byte boundary this will result in passing an
>unaligned address to futex. I haven't yet decided on what would be
Wouter Verhelst writes:
> Does anyone know what the status of this support is in libc?
It is basically working quite well. Unfortunately there is a big
problem which becomes apparent when running the libstdc++ testsuite: the
m68k compiler only guarantees a maximum alignment of 2 bytes, but the
On Tue, 20 Apr 2010, Thorsten Glaser wrote:
> fth...@telegraphics.com.au dixit:
>
> >Anyway, since these are native builds, steps 3+ need to happen running
> >under a kernel with TLS support (which could be built with a plain
> >etch-m68k tool chain last time I tried it). You also need the ker
fth...@telegraphics.com.au dixit:
>One possible solution for a native build is, in sequence,
>
>1. binutils
>2. gcc
>3. libc
>4. gcc
>5. libc
>
>...installing each package as it is built, before building the next one.
That was approximately how I planned it. (Why is it that gcc needs,
at build t
On Tue, 20 Apr 2010, I wrote:
> and you need [glibc with NPTL] before you can build gcc with TLS.
Well, this isn't quite right. I'm told that you can get __thread support
from gcc 4.5 without having to have NPTL support in your libc.
Problem is, that compiler will have fixed includes, libgcc,
On Mon, 19 Apr 2010, Thorsten Glaser wrote:
> Wouter Verhelst dixit:
>
> >could we look into re-bootstrapping the port and starting to build
>
> I?m currently building gcc-4.4 and other up-to-date packages. Once I get
> gcc-4.4 to work ... we can ask doko to put the patches into 4.4.
>
> Then
Wouter Verhelst dixit:
>could we look into re-bootstrapping the port and starting to build
I’m currently building gcc-4.4 and other up-to-date packages. Once
I get gcc-4.4 to work (got multiarch/multilib working, but libfortran
can't be built for -mfidoa due to incompatible inline assembly in a
s
On Mon, Apr 19, 2010 at 09:33:54PM +1000, fth...@telegraphics.com.au wrote:
>
> On Mon, 19 Apr 2010, Wouter Verhelst wrote:
>
> > Does anyone know what the status of this support is in libc?
>
> This was the situation a month ago--
> http://lists.debian.org/debian-68k/2010/03/msg00014.html
Righ
On Mon, Apr 19, 2010 at 01:01:38PM +0200, Wouter Verhelst wrote:
> > Well, motivation is somewhat lower after not being an official part of
> > Debian anymore, but I still like m68k and would keep my machines running.
> I could revive some hosts, too, though it would involve some work.
> But the p
On Mon, 19 Apr 2010, Wouter Verhelst wrote:
> Does anyone know what the status of this support is in libc?
This was the situation a month ago--
http://lists.debian.org/debian-68k/2010/03/msg00014.html
It appears that the eglibc repo has the patches in HEAD now.
Finn
--
To UNSUBSCRIBE, email
On Mon, Apr 19, 2010 at 12:05:39PM +0200, Ingo Jürgensmann wrote:
> On Mon, Apr 19, 2010 at 11:43:29AM +0200, Wouter Verhelst wrote:
>
> > Or have we collectively lost interest and should we just let it die?
>
> Well, motivation is somewhat lower after not being an official part of
> Debian anymo
On Mon, Apr 19, 2010 at 11:43:29AM +0200, Wouter Verhelst wrote:
> Or have we collectively lost interest and should we just let it die?
Well, motivation is somewhat lower after not being an official part of
Debian anymore, but I still like m68k and would keep my machines running.
So, when there's
Hi all,
GCC 4.5 was released not so long ago, and one of the new features listed
on its changes page[1] is TLS support for m68k/ColdFire.
Does anyone know what the status of this support is in libc? If so,
could we look into re-bootstrapping the port and starting to build
up-to-date packages agai
42 matches
Mail list logo
