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 need support for the
> '
On Tue, 22 May 2007, Michael Schmitz wrote:
> > > Plus we already reserve a register for the current task - we're not all
> > > that squeezed, but can't we store the per thread data at a constant offset
> > > from the task address which we already store in a register? Are all
> > > threads separate
> > Plus we already reserve a register for the current task - we're not all
> > that squeezed, but can't we store the per thread data at a constant offset
> > from the task address which we already store in a register? Are all
> > threads separate tasks at kernel level?
>
> We already reserve a reg
On Tue, 22 May 2007, Michael Schmitz 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 implem
> > 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
On Fri, May 18, 2007 at 11:05:31AM -0700, Brad Boyer wrote:
> 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 imp
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
> > still not the case for m
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
> state.
The last tim
14 matches
Mail list logo
