> I have no immediate plans. If you have time to knock something
> together for Sparc, that would be fantastic.
Btw, any particular reason why the libgomp-copied linking scheme seems to be
only half-implemented?
# Set up the set of libraries that we need to link against for libitm.
# Note that
> I have no immediate plans. If you have time to knock something
> together for Sparc, that would be fantastic.
OK, will try, thanks.
--
Eric Botcazou
On 01/10/2012 05:52 AM, Eric Botcazou wrote:
>> To get the ball rolling for other targets, and to let port maintainers see
>> how easy it really is, here's a first cut at a port to ARM.
>
> Do you plan to do something for the SPARC? I'm asking because you still are
> a
> maintainer of this arch
> To get the ball rolling for other targets, and to let port maintainers see
> how easy it really is, here's a first cut at a port to ARM.
Do you plan to do something for the SPARC? I'm asking because you still are a
maintainer of this arch as well, so if we can avoid doing the work twice...
--
On Thu, 24 Nov 2011, Richard Henderson wrote:
> On 11/24/2011 02:34 AM, Richard Earnshaw wrote:
> > What about systems with floating-point or vector registers? Ie VFP or
> > WMMX on XScale? Do the callee saved registers in those register banks
> > also have to be saved?
>
> Yes.
>
> I mis-read
On 11/24/2011 02:34 AM, Richard Earnshaw wrote:
> What about systems with floating-point or vector registers? Ie VFP or
> WMMX on XScale? Do the callee saved registers in those register banks
> also have to be saved?
Yes.
I mis-read both the glibc and gcc sources on the matter, assuming
that on
Richard Henderson wrote:
> To get the ball rolling for other targets, and to let port maintainers see
> how easy it really is, here's a first cut at a port to ARM.
I've tried to port libitm to SH based on the ARM patch.
The attached patch is tested on sh4-unknown-linux-gnu:
===
On 11/24/2011 02:34 AM, Richard Earnshaw wrote:
>> + unsigned long s[8]; /* r4-r12 */
>
> R4-R12 is 9 registers. But R12 is callee clobbered. So is the code or
> the comment incorrect?
The comment is clearly a typo.
>> +/* ARM generally uses a fixed page size of 4K. */
>> +#define PAGE
On 23/11/11 23:47, Richard Henderson wrote:
> To get the ball rolling for other targets, and to let port maintainers see
> how easy it really is, here's a first cut at a port to ARM.
>
> Only cross-compiled as yet, and qemu-linux-user isn't good enough to emulate.
> I'll do another build on the
On 24/11/11 02:23, Richard Henderson wrote:
> On 11/23/2011 04:00 PM, Joseph S. Myers wrote:
>> On Wed, 23 Nov 2011, Richard Henderson wrote:
>>
>>> + __asm volatile ("swi %1"
>>> + : "+r"(sc_0)
>>> + : "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
>>> + : "me
On Wed, 23 Nov 2011, Richard Henderson wrote:
> On 11/23/2011 04:00 PM, Joseph S. Myers wrote:
> > On Wed, 23 Nov 2011, Richard Henderson wrote:
> >
> >> + __asm volatile ("swi %1"
> >> +: "+r"(sc_0)
> >> +: "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
> >> +
On 11/23/2011 04:00 PM, Joseph S. Myers wrote:
> On Wed, 23 Nov 2011, Richard Henderson wrote:
>
>> + __asm volatile ("swi %1"
>> + : "+r"(sc_0)
>> + : "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
>> + : "memory");
>
> That looks wrong. Passing the sysc
On Wed, 23 Nov 2011, Richard Henderson wrote:
> + __asm volatile ("swi %1"
> + : "+r"(sc_0)
> + : "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
> + : "memory");
That looks wrong. Passing the syscall number to swi is the old-ABI
approach; the EABI use
On 11/23/2011 03:47 PM, Richard Henderson wrote:
> +GTM_longjmp:
> + ldm r0, { r4-r11, sp, pc }
Bah. This should be
mov r2, r0 /* Move the jmpbuf out of the way. */
mov r0, r1 /* Move the return value into place. */
ldm r2, { r4-r1
To get the ball rolling for other targets, and to let port maintainers see how
easy it really is, here's a first cut at a port to ARM.
Only cross-compiled as yet, and qemu-linux-user isn't good enough to emulate.
I'll do another build on the armv7 host once my current bootstrap and test for
th
15 matches
Mail list logo
