Hi Finn!
On 1/29/23 01:15, Finn Thain wrote:
The developers of the TLS/NPTL support for m68k/coldfire were working for
Freescale and Codesourcery at the time...
https://lists.debian.org/debian-68k/2008/02/msg00212.html
https://lists.debian.org/debian-68k/2007/11/msg00071.html
Thanks, these
Well afaics Linux/m68k sacrificed a global register (A5 ?) for TLS so that
should be the easy start.
Not sure if the concept of threads, TLS and such makes any sense on AmigaOS or
TOS. Most likely fairly irrelevant as those have a substantially different
process/thread model than POSIX
Hi,
On Sat, 28 Jan 2023, Chris Hanson wrote:
> That said, any compiler or linker for 68K needs to support multiple ABI
> standards since Mac OS, Atari, Amiga, and all the different UNIX and
> UNIX-like operating systems had their own ABI. Fortunately LLVM itself
> supports the concept of multiple
On Sat, 28 Jan 2023, John Paul Adrian Glaubitz wrote:
> Hello!
>
> The maintainers of the m68k backend in LLVM have started initial
> planning for adding TLS support. An issue for that has been opened in
> the LLVM Github tracker [1].
>
> If anyone can help shed more l
There wasn't really a TLS standard on any 68K ABIs that I know about. If the
SVR4 ABI for 68K defined one then that's probably the one I'd use for LLVM's
default, as most everything else should follow the SVR4 ABI for 68K by default
too, right?
That said, any compiler or
Hello!
The maintainers of the m68k backend in LLVM have started initial planning for
adding
TLS support. An issue for that has been opened in the LLVM Github tracker [1].
If anyone can help shed more light on how TLS works on m68k, please add your
comments
to this Github issue. Any
Hi!
There is a bug in M68K LLVM backend which, according to the upstream maintainer,
might be related to an issue with TLS on m68k, see [1].
Could anyone with some insight on the TLS code in glibc chime in?
Thanks,
Adrian
[1] https://github.com/llvm/llvm-project/issues/59161#issuecomment
Drew Parsons writes:
> The link error suggests 2 different versions of MPIUI_Thread are used.
> But I can only see a definition in src/util/thread/mpiu_thread.c.
> src/mpi/comm does not refer to it, and comm_rank.c does not use any
> MPIU object. So the error message doesn't make sense to me.
c
mpich has been consistently failing to build on sh4.
The error occurs when linking the static library with the message:
/usr/bin/ld: MPIUI_Thread: TLS definition in
lib/.libs/libmpich.a(lib_libmpich_la-mpiu_thread.o) section .tbss mismatches
non-TLS reference in lib/.libs/libmpich.a
On Thu, Aug 22, 2013 at 3:37 PM, Joseph S. Myers
wrote:
> On Thu, 22 Aug 2013, Geert Uytterhoeven wrote:
>
>> > The vDSO support has been there in glibc ever since the NPTL port was
>> > first added. I've no idea why the kernel changes still haven't gone in.
>>
>> I didn't know that. Seems to be
On Thu, 22 Aug 2013, Geert Uytterhoeven wrote:
> > The vDSO support has been there in glibc ever since the NPTL port was
> > first added. I've no idea why the kernel changes still haven't gone in.
>
> I didn't know that. Seems to be recent work, cfr.
> https://github.com/Xilinx/glibc/blob/master
the ABI and should be faster than the TLS system
>> calls.
>
> The vDSO support has been there in glibc ever since the NPTL port was
> first added. I've no idea why the kernel changes still haven't gone in.
I didn't know that. Seems to be recent work, cfr.
https://githu
VDSO (as well as the atomic ops). As I
>> >understand it, this need not break the ABI and should be faster than
>> >the TLS system calls.
>>
>> It will not break the ABI, but how'd it work?
>>
>> - One kernel/user shared, readonly, page global (for t
On Thu, 22 Aug 2013, Finn Thain wrote:
> Losing a register also hurts performance. Someone suggested moving
> get/set_thread_area to a VDSO (as well as the atomic ops). As I understand
> it, this need not break the ABI and should be faster than the TLS system
> calls.
The vDSO
. A new
ABI could then come about as a consequence of removal of baggage and
optimisation (presuming a performance increase to justify it).
>
> >get/set_thread_area to a VDSO (as well as the atomic ops). As I
> >understand it, this need not break the ABI and should be faster th
gt;get/set_thread_area to a VDSO (as well as the atomic ops). As I understand
>it, this need not break the ABI and should be faster than the TLS system
>calls.
It will not break the ABI, but how’d it work?
• One kernel/user shared, readonly, page global (for time, atomic)
• One kernel/user sha
On Wed, 21 Aug 2013, Thorsten Glaser wrote:
> >> Anything GTK+/GNOME (e.g. xchat) is not usable due to their use of
> >> TLS and/or atomics. I had thought KDE would suffer from the same, but
> >> they seem to be faster?
> >
> >We do have TLS now, do
On Wed, Jun 08, 2011 at 07:41:35PM +, Thorsten Glaser wrote:
> Dominic Hargreaves dixit:
>
> >FYI: the patch has now gone upstream in any case:
> […]
> >Although if anyone has any strong feelings about it, do let us know.
>
> How about this?
>
>
> Hi Jesse,
>
> our paths cross again (remem
6 Mon Sep 17 00:00:00 2001
From: Thorsten Glaser
Date: Wed, 8 Jun 2011 21:36:08 +0200
Subject: [PATCH] There is TLS support on Debian/m68k, but the architecture is
slow.
Revert 4a278ec85c28bdfcfeffd327eb483181131afb8e (re-enable the
stress.t and waithires.t tests) and raise the timeout on m68k
(not ju
On Tue, Jun 07, 2011 at 08:11:33PM +, Thorsten Glaser wrote:
> Dominic Hargreaves dixit:
>
> >If you raise $TIMEOUT in that test file, do you get any further?
>
> root@ara5:~/perl-5.12.3 # perl dist/threads-shared/t/stress.t
> 1..1
> ok 1
> root@ara5:~/perl-5.12.3 # fgrep TIMEOUT\ = dist/thre
/errno_ver - http://bugs.debian.org/343351 Remove
> Errno version check due to upgrade problems with long-running
> processes.
> DEBPKG:debian/extutils_hacks - Various debian-specific ExtUtils
> changes
> DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to
>
Dominic Hargreaves dixit:
>If you raise $TIMEOUT in that test file, do you get any further?
root@ara5:~/perl-5.12.3 # perl dist/threads-shared/t/stress.t
1..1
ok 1
root@ara5:~/perl-5.12.3 # fgrep TIMEOUT\ = dist/threads-shared/t/stress.t
my $TIMEOUT = 600;
Note that this is an (emulated) fas
On Tue, Jun 07, 2011 at 06:46:16PM +, Thorsten Glaser wrote:
> Dominic Hargreaves dixit:
>
> >- DEB_BUILD_OPTIONS=nocheck debuild -us -uc
>
> I skipped that part because I already have the latest
> Perl built and installed some time ago.
>
> >- Revert debian/patches/debian/m68k_thread_stress
ndor.
DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as
per Debian policy.
DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to
/etc/perl/Net as /usr may not be writable.
DEBPKG:debian/m68k_thread_stress - http://bugs.debian.org/495826
Disa
On Sun, Jun 05, 2011 at 04:52:09PM +, Thorsten Glaser wrote:
> Dominic Hargreaves dixit:
>
> >[please retain Cc to p...@packages.debian.org]
>
> >Is this still needed? I see some evidence on the Debian ports web
> >pages that TLS is now available.
>
> Th
Dominic Hargreaves dixit:
>[please retain Cc to p...@packages.debian.org]
>Is this still needed? I see some evidence on the Debian ports web
>pages that TLS is now available.
There is TLS, yes – but I currently don’t run the testsuite
when compiling. Once we’ve got a buildd back r
[please retain Cc to p...@packages.debian.org]
Hi,
I'm looking through some old perl patches we apply; one is
<http://patch-tracker.debian.org/patch/series/view/perl/5.12.3-7/debian/m68k_thread_stress.diff>
Is this still needed? I see some evidence on the Debian ports web
pages that
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 t
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 quest
-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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In pe
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 trie
it that gcc needs,
at build time, the headers of the target system for GNU libc based
systems? It doesn’t need them for, for example, a cross-compiler
targetting MirBSD.)
>(I haven't tried this. Perhaps the TLS devs can chime in?)
-v -h please.
>Anyway, since these are native builds, s
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 inc
the patches into 4.4.
>
> Then we can tackle 4.5 and, after that, eglibc, I think.
Obviously, the sid archive stands much a better chance with the sid
compiler, so there's no rush to build 4.5 if sid is the objective (?)
BTW, you'll need kernel headers with TLS support before you can bu
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
On Wed, Apr 23, 2008 at 10:08:53AM +, Joseph S. Myers wrote:
> On Tue, 22 Apr 2008, Stephen R Marenka wrote:
>
> > On Fri, Nov 30, 2007 at 07:05:05PM +, Joseph S. Myers wrote:
> > > CodeSourcery has been investigating implementing TLS (Thread-Local
> > > S
On Tue, 22 Apr 2008, Stephen R Marenka wrote:
> On Fri, Nov 30, 2007 at 07:05:05PM +, Joseph S. Myers wrote:
> > CodeSourcery has been investigating implementing TLS (Thread-Local
> > Storage) and NPTL (Native POSIX Thread Library) for ColdFire
> > processors. The
On Fri, Nov 30, 2007 at 07:05:05PM +, Joseph S. Myers wrote:
> CodeSourcery has been investigating implementing TLS (Thread-Local
> Storage) and NPTL (Native POSIX Thread Library) for ColdFire
> processors. The proposed TLS ABI for ColdFire and m68k, including the
> required kerne
On Mon, Dec 03, 2007 at 06:40:27PM +0100, Roman Zippel wrote:
> I've already played with a vdso implementation and played with a few
> possibilities, there are subtle problems when writing to that page (e.g.
> by the debugger via ptrace), so that at the next context switch the
> correct thread v
On Sun, Dec 02, 2007 at 11:43:18PM +, Joseph S. Myers wrote:
> On Sun, 2 Dec 2007, Brad Boyer wrote:
> > I also tried to look for the ARM magic page implementation, but I
> > couldn't find it. Any pointers to where I should be looking? I've
> > never done any work on ARM other than looking at s
to end up as a syscall (as used on ARM), given that it's not
> critical and it may be required too early in startup for the vDSO to be
> usable.
Even for early startup I don't see that it would need all registers, so
that a consistent calling convention is IMO more important.
es in line
> with above.
It might need to end up as a syscall (as used on ARM), given that it's not
critical and it may be required too early in startup for the vDSO to be
usable.
> > The same issue as for GOT accesses also applies to accesses to TLS
> > data using the
Hi,
On Fri, 30 Nov 2007, Joseph S. Myers wrote:
> Kernel helpers
> --
>
> This TLS ABI defines a function __m68k_read_tp, provided by libc.
> This returns the thread pointer in register a0 (not d0) and may
> clobber other call-clobbered registers. The compiler wil
Hi,
On Fri, 30 Nov 2007, Brad Boyer wrote:
> I presume ColdFire is also missing CAS2. Do we need a 64 bit cmpxchg
> equivalent as well?
cas2 is an emulated instruction on 68060, so we might want to avoid direct
usage on m68k as well.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> I suppose we could add a page at a fixed virtual offset from the vDSO
> base address. That would make the code sequence easier since we would
> presumably could use PC-relative addressing in the vDSO code. This would
> be much better than having a fixed virtual address. I'm just worried
> about
On Sun, 2 Dec 2007, Brad Boyer wrote:
> I also tried to look for the ARM magic page implementation, but I
> couldn't find it. Any pointers to where I should be looking? I've
> never done any work on ARM other than looking at some of the chip
> documentation and some decidedly non-Linux implementat
On Sat, Dec 01, 2007 at 01:08:07AM +, Joseph S. Myers wrote:
> On Fri, 30 Nov 2007, Brad Boyer wrote:
> > > * There are no spare registers available to designate as the thread
> > > register. Therefore, kernel magic is needed to obtain the thread
> > > pointer from userspace. Kernel helpe
On Sat, 1 Dec 2007, Joseph S. Myers wrote:
> On Fri, 30 Nov 2007, Brad Boyer wrote:
> > Can you get SMP ColdFire boxes? Linux has historically not supported
> > SMP on m68k, and much of the code isn't really SMP safe (particularly
> > some of the drivers for 68k based systems). This isn't to say we
On Fri, 30 Nov 2007, Brad Boyer wrote:
> > * There are no spare registers available to designate as the thread
> > register. Therefore, kernel magic is needed to obtain the thread
> > pointer from userspace. Kernel helpers are provided in a vDSO since
> > they will need unwind information
On Fri, Nov 30, 2007 at 07:05:05PM +, Joseph S. Myers wrote:
> CodeSourcery has been investigating implementing TLS (Thread-Local
> Storage) and NPTL (Native POSIX Thread Library) for ColdFire
> processors. The proposed TLS ABI for ColdFire and m68k, including the
> required kerne
CodeSourcery has been investigating implementing TLS (Thread-Local
Storage) and NPTL (Native POSIX Thread Library) for ColdFire
processors. The proposed TLS ABI for ColdFire and m68k, including the
required kernel interfaces, is below; any comments?
We do not at present have a timescale for the
On Mon, May 21, 2007 at 10:25:04AM -0700, Brad Boyer wrote:
[TLS support]
> I don't think m68k would have issues with large relocation offsets. As
> long as it doesn't support the pre-68020 chips, we have a lot of choices
> of ways to handle large offsets. I presume we just n
in a register? Are all
> > > threads separate tasks at kernel level?
> >
> > We already reserve a register for the current task in kernel space.
> > [...]
> > While TLS needs some kind of pointer in user space.
> > (Of course the kernel has to update the memory poin
el level?
>
> We already reserve a register for the current task in kernel space.
> [...]
> While TLS needs some kind of pointer in user space.
> (Of course the kernel has to update the memory pointer at every task
> switch).
That's what I meant. Can the TLS pointer be derive
e simpler option in the short term is via a memory pointer, an ABI
> > change needs a lot more preparation (although it's desirable in the long
> > term to also fix other things).
>
> Let's focus on the simpler option first :-)
While TLS needs some kind of pointer in
> > I'd like to avoid following in the footsteps of the i386 style support
> > particularly because it does require more extensive kernel support than
> > most of the other architectures. I'm still looking over the documentation
> > and the implementation details of the other architectures, but I'l
Hi,
On Mon, 21 May 2007, Brad Boyer wrote:
> I'd like to avoid following in the footsteps of the i386 style support
> particularly because it does require more extensive kernel support than
> most of the other architectures. I'm still looking over the documentation
> and the implementation detail
On Mon, May 21, 2007 at 04:23:15PM +0200, Michael Schmitz wrote:
> > > >From my quick reading, we might have to sacrifice another register. Does
> > > this require any special handling at the kernel level?
> > >
> > > I'd look at the 386 implementation (SH seems a bit simpler but I do know
> > > sq
> > >From my quick reading, we might have to sacrifice another register. Does
> > this require any special handling at the kernel level?
> >
> > I'd look at the 386 implementation (SH seems a bit simpler but I do know
> > squat about SH - anyone?)
>
> But I guess SH looks more like m68k than ia32,
On Mon, 21 May 2007, Michael Schmitz wrote:
> > Is this the document?
> >
> > http://people.redhat.com/drepper/tls.pdf
> >
> > It does seem to have quite a bit of technical detail. I'll look at it
> > in more depth a little later. Thank you for the pointer.
>
> >From my quick reading, we might hav
> Is this the document?
>
> http://people.redhat.com/drepper/tls.pdf
>
> It does seem to have quite a bit of technical detail. I'll look at it
> in more depth a little later. Thank you for the pointer.
>From my quick reading, we might have to sacrifice another register. Does
this require any speci
r the pointer.
It is indeed. I don't think you'll read any better documentation about
TLS elsewhere.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgp6nZGQDvmxd.pgp
Description: PGP signature
On Fri, May 18, 2007 at 07:35:07PM +0200, Pierre Habouzit wrote:
> There is a quite good pdf on Uli's page. Search Ullrich Drepper on
> google, you should be able to find it. IIRC there is the explanation on
> how it has been implemented for a few archs, quite extensively annotated.
Is this the
On Fri, May 18, 2007 at 09:40:53AM -0700, Brad Boyer wrote:
> On Fri, May 18, 2007 at 03:20:00PM +0200, Pierre Habouzit wrote:
> > You were previously made aware[0] that glibc-2.6 needs TLS to be
> > implemented for your ports to build and work properly, sadly this is
> > s
On Fri, May 18, 2007 at 03:20:00PM +0200, Pierre Habouzit wrote:
> You were previously made aware[0] that glibc-2.6 needs TLS to be
> implemented for your ports to build and work properly, sadly this is
> still not the case for m68k, and insufficient for Hurd in the current
> stat
Hi,
On Mon, 23 Oct 2006, Geert Uytterhoeven wrote:
> > > Which alignment do you mean? 32-bit values aligned on a 2-byte boundary?
> >
> > Yes, it causes all kind of stupid bugs, which only trigger on m68k...
>
> But if you change it, how much software that does handle it correctly now will
> br
1 - 100 of 108 matches
Mail list logo
