[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-mips
Subject:    Re: [PATCH] Retrieval of TLS pointer via RDHWR
From:       Robert Millan <rmh () debian ! org>
Date:       2011-08-03 1:29:29
Message-ID: CAOfDtXP20PQfLbYyZNOHSjQb9QpJ3h81mjhQBk9kThkEyrrmRg () mail ! gmail ! com
[Download RAW message or body]

2011/1/10 Jayachandran C. <c.jayachandran@gmail.com>:
> |+                                              trapframe->pc += sizeof(int);
>
> This will mis-behave if the rdhwr is in a branch delay slot. You
> should either signal 'SIGILL' in this case or do an emulate branch (if
> the rdhwr is can be used in a branch delay slot).

Excuse me for the delay in replying, I had to investigate to figure
this out and didn't find the time.

It appears that rdhwr is allowed in a branch delay slot, but since it
is known to be more costly, GCC developers avoid using it there, see:

http://gcc.gnu.org/ml/gcc/2006-07/msg00488.html
http://gcc.gnu.org/ml/gcc/2006-07/msg00494.html

So I guess it'll be best to emulate it for correctness, knowing that
this path will seldom be used.  What do you think?

Another doubt I have is that I don't get the distinction between the
trapframe here:

        struct thread *td = curthread;
[...]
                        struct trapframe *locr0 = td->td_frame;

and this one:

register_t
trap(struct trapframe *trapframe)
{

Do both correspond to userland CPU context for current thread?

Thanks!

-- 
Robert Millan
_______________________________________________
freebsd-mips@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"

[prev in list] [next in list] [prev in thread] [next in thread]