Porting glibc to Coldfire

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Porting glibc to Coldfire

Richard Sandiford-3
This patch ports glibc to Coldfire.  It was tested with the kernel
from Freescale's CWF-MCF547X-548X-2-6-KL BSP:

    http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWB-MCF547X-548X-2-6-KL&srch=1

with this additional patch from Freescale applied:

    http://www.codesourcery.com/archives/coldfire-gnu-discuss/msg00041.html

Everything was compiled with the csl/coldfire-4_1 branch of gcc:

    svn://gcc.gnu.org/svn/gcc/branches/csl/coldfire-4_1

which we hope to merge into mainline after 4.2 has branched.

Coldfire vs. m680x0
===================

I suppose one fundamental question is: should Coldfire be treated as
a separate port from m68k, or as a subport?  Although there are several
differences between Coldfire and m680x0, I think the architectures are
similar enough to justify treating them as variations of the same base
port.  gcc, linux and uClinux have done the same thing.

The patch therefore adopts the following directory structure:

    sysdeps/.../m68k/{,fpu/}
    sysdeps/.../m68k/m680x0/{,fpu/}
    sysdeps/.../m68k/m680x0/m68020/{,fpu/}
    sysdeps/.../m68k/coldfire/{,fpu/}

so that files can classified as m680x0-only, Coldfire-only, or suitable
for both.  This involves moving a lot of files from m68k/ to m68k/m680x0/,
and because a patch to do that would be almost unreadable, I've attached
a shell script to do it instead.  I've made the main patch relative to
the moved files.

If a file only needs small changes for Coldfire, I've kept it in
sysdeps/.../m68k/ and used __mcoldfire__ or __mcffpu__ to select
the Coldfire parts.  Obviously it's a judgement call as to how much
variation can be treated as "small", but I hope the balance seems OK.

If no processor is specifically selected by the target triplet, the patch
to sysdeps/m68k/preconfigure will use the compiler to choose between m680x0
or Coldfire as appropriate.

Generic m68k fixes
==================

I came across a few problems with the existing m68k port.  Because I've
got no way of testing the port without the Coldfire support, and because
one or two of the fixes are in code that is sensitive to the Coldfire/m680x0
distinction, I'm afraid everything's lumped together.  The fixes are fairly
simple though.  Specifically:

- sysdeps.h didn't guard against multiple inclusion.

- The definitions of feholdexcept and fesetround were missing
  a libm_hidden_def().

- setjmp.c used hidden_def() rather than libc_hidden_def(), which led to:

    error: '__EI___sigsetjmp' aliased to undefined symbol '__GI___sigsetjmp'

  I've changed it to use libc_hidden_def() instead.

- In dl-trampoline.S:

  - The code that rounds the frame size used "lsr" (implicitly "lsr.w")
    rather than lsr.l, causing it to mishandle large frames:

  | Round framesize up to even
  addq.l #1, %d1
        lsr #1, %d1
  sub.l %d1, %a0
  sub.l %d1, %a0

  - The code that calls _dl_call_pltexit() failed to initialize the
    lrv_a0 field of the outregs parameter, which in turn meant that
    the contents of lrv_fp0 were at the wrong offset.  Also, the inregs
    parameter pointed 4 bytes below the structure it was supposed to
    point at.

    I've fixed these problems and adjusted the stack offsets of other
    data to account for the extra field.

- The port was missing ldsodefs.h and tst-audit.h.  These files are
  needed because upstream sources no longer provide the m68k definitions.

- struct fpregset was out of sync with linux.  linux puts the
  data registers after the control registers, but glibc had them
  the other way round.

- The layout of struct ucontext was also out of sync with linux.
  uc_sigmask should come after uc_filler, and uc_filler should
  have 80 rather than 174 elements.

- m68k glibc was using the standard linux layout of struct siginfo, but
  m68k linux uses a different layout.  It appears that the uid fields
  were once 16-bit fields on m68k linux, and that, to avoid breaking
  backward compatibility, 32-bit versions were later tacked on to the
  end of each substructure.  I've therefore added an m68k linux-specific
  siginfo.h file.

- The generic implementation of wcpcpy.c accesses the source string
  using an offset from the destination string:

    wchar_t *
    __wcpcpy (dest, src)
         wchar_t *dest;
         const wchar_t *src;
    {
      wchar_t *wcp = (wchar_t *) dest - 1;
      wint_t c;
      const ptrdiff_t off = src - dest + 1;

      do
        {
          c = wcp[off];
          *++wcp = c;
        }
      while (c != L'\0');

      return wcp;
    }

  which means that sizeof (wchar_t) must be __alignof__ (wchar_t).
  On m68k, the values are 4 and 2 respectively, so the routine won't
  work if ((intptr_t) dest % 2) != ((intptr_t) src % 2).

  wcscpy.c (which was written a year earlier) does check the alignment,
  and so works out of the box on m68k.  I don't think there's any chance
  of getting the upstream version of wcpcpy.c changed in the same way,
  so I've added a port-local version.  I've also done the same for
  wcpcpy-chk.c, which has the same problem.

- m68k/sysdep-cancel.h wrongly treated __librt_multiple_threads as
  hidden, and the assembler version of SINGLE_THREAD_P used PC-relative
  addressing to access it.  I've removed the hidden attribute and made
  librt's SINGLE_THREAD_P load the symbol from the GOT instead.  The new
  implementation of SINGLE_THREAD_P needs a temporary address register,
  which is passed as an argument to the macro.

Optimizations
=============

I had to change the implementation of the string and memory functions
for Coldfire, and noticed that some of them could be optimized slightly.
When trying to reach an alignment boundary, the current code moves the
address into a data register and "and"s it with 3 to see if it is
already aligned.  If it isn't aligned, the code would repeat the check
one byte later, and again for the byte after that.  It would be simpler
to use subq and addq on the first "and" result instead.  (We can use
addq.w and subq.w on m680x0.)  From what I remember of 68000, I think
this is better for 680x0 targets too.

Coldfire changes
================

The main differences between the Coldfire and m680x0 code are as follows:

- FPU differences:

  - FP registers are 64 bits rather than 96 bits wide.

  - Coldfire does not have the 68881's fmovem.l; we must save and restore
    individual control registers.

  - Long doubles are the same as doubles.

  - The canonical NaN has all significand bits set.  Some files in
    ieee754/dbl-64 use hard-coded hex constants, so I've overridden
    them (e_pow.c, s_sin.c and u_remainder.c).

  - Unlike the 68881, the Coldfire FPU lets you raise exceptions by
    setting the appropriate EXC bits of the FPSR and then executing
    an arithmetic instruction.  This makes the implementation of
    fraiseexcpt.c easier.

  - The Coldfire FPU has a much smaller set of instructions than the 68881.
    The functions it does support directly are: fabs(), sqrt(), lrint()
    rint(), and their float and long double equivalents.

- ISA differences:

  - 32-bit PC-relative offsets must be loaded into a register and then
    applied using offset(%pc,reg).  I've added a PCREL_OP macro to wrap up
    this difference.

  - Coldfire does not have jmp (%dN) and jsr (%dN).  Those instructions are
    used in dl-trampoline.S in cases where every address register is live,
    so I've simulated them using push and rts instructions.

  - Coldfire strongly prefers a 32-bit aligned stack pointer, so I've
    rounded frame sizes up to longword rather than word alignment.

  - Coldfire does not have dbra, exg or word-sized register operations.

- Kernel differences:

  - FPU-related fields are often laid out differently.

  - FP registers have different ptrace() numbers.

  - sigcontext has fields for all registers, avoiding the need for the
    real_catch_segfault hack in register-dump.h.

- Coldfire has no atomic compare-and-swap instruction and the kernel
  does not yet have any userspace atomicity support.  I've therefore
  used the generic bits/atomic.h implementation, but with the addition
  of the now-required atomic*_t types.  (I don't think upstream would
  allow these types to be added to the generic bits/atomic.h as none of
  the core targets use that file.)

Compatibility
=============

Because Coldfire is a new port, we don't need to be compatible with
versions before 2.4.  So:

- I've set the default version to GLIBC_2.4 in
  sysdeps/m68k/coldfire/shlib-versions.

- I've moved oldgetrlimit and oldsetrlimit from
  sysdeps/unix/sysv/linux/m68k/syscalls.list to the new
  sysdeps/unix/sysv/linux/m68k/m680x0/syscalls.list.

Expected test faliures
======================

As far as the testsuite goes, some tests failed for me because of the
usual environmental limitations.  For example, the board had only 64MB
of RAM, which isn't enough for some tests, and the root fs was
NFS-mounted, which causes tests like tst-utmp and tst-utmpx to fail.

There are some expected non-environment failures too:

math/test-misc.out
misc/tst-efgcvt.out
stdio-common/tst-printf.out

  - These tests require correct subnormal handling.  The kernel does
    not yet emulate subnormal operations.

build rt/tst-aio2.o
build rt/tst-aio3.o

  - These tests should (but don't) include <pthread.h>, as they refer
    to PTHREAD_BARRIER_SERIAL_THREAD.  Changes are unlikely to be
    accepted upstream because NPTL ports presumably work as-is.

rt/tst-aio10.out
rt/tst-aio9.out

  - A LinuxThreads limitation.  We implement lio_listio using
    pthread_cond_wait, which does not stop and return EINTR when
    a signal is raised.  NPTL avoids this using aio_misc.h.

math/test-double.out
math/test-float.out
math/test-idouble.out
math/test-ifloat.out

  - All four tests fail some llrint_upward and llrint_downward checks
    because of a bug in the generic llrint.c code; see bug #2592.
    test-float.out and test-double.out also fail because the Coldfire
    FPU does not distinguish between quiet and signalling NaNs;
    all NaN inputs raise an Invalid Operation exception.

As a sanity check, I've also built a 68020 glibc.  I used
csl/coldfire-4_1 again, but with the attached mainline backports applied,
and with gcc configured using --with-cpu=68020 and --with-float=hard.

The patch is in three pieces; the initial move-only script, the main
ports patch, and a linuxthreads patch.  There is talk of supporting
NPTL in future, but nothing definite yet.

Please install if OK.

Richard


glibc-move.clog (8K) Download Attachment
glibc-move.sh (3K) Download Attachment
glibc.clog (4K) Download Attachment
glibc.diff (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
Richard Sandiford <[hidden email]> writes:

>   - The canonical NaN has all significand bits set.

This is not different to the 68881.  Since any non-zero bit pattern
qualifies as NaN that should not be a problem.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:
> Richard Sandiford <[hidden email]> writes:
>
>>   - The canonical NaN has all significand bits set.
>
> This is not different to the 68881.  Since any non-zero bit pattern
> qualifies as NaN that should not be a problem.

Right, all nonzero significands do of course count as NaN.  But it
depends what you mean by "problem".  I think it's worthwhile allowing
users to assume that the NaNs of the same sign produced by one function
will have the same bit pattern as NaNs produced by another.  In other
words, it's a QoI issue.

The coldfire branch of gcc is careful to use the canonical NaN for
__builtin_nan(""), and there are actually tests in gcc.c-torture/execute/ieee
to ensure that it does.  The glibc values I'm overriding are the hard-coded
equivalent of __builtin_nan(""), and I'd like glibc to be consistent.

That said, I realise I made a stupid error; I called one of the files
u_remainder.c rather e_remainder.c ;(.  I must have been thinking of
the header file (urem.h) or something.

I hadn't realised that the 68881 had the same canonical NaN.  However,
it provides its own representation of the affected files, so I believe
they will already return the canonical forms.

What were you thoughts on the rest of the patch?  Did it look
OK otherwise?

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Wouter Verhelst-2
In reply to this post by Richard Sandiford-3
Hi,

(I'm not subscribed to the list, but got pointed to this mail by Martin
Michlmayr; I don't think followups will be necessary, but if they are,
please do Cc me)

Richard Sandiford:
[...]
> Coldfire vs. m680x0
> ===================
>
> I suppose one fundamental question is: should Coldfire be treated as
> a separate port from m68k, or as a subport?  Although there are several
> differences between Coldfire and m680x0, I think the architectures are
> similar enough to justify treating them as variations of the same base
> port.  gcc, linux and uClinux have done the same thing.

Just to add my two cents...

Seen as how I'm currently trying to get Debian/m68k (which is the only
current GNU/Linux distribution for m68k) to work on ColdFire V4e too, in
addition to "classic" 68k hardware, I would very much appreciat that; it
would make my work a lot easier.

Not that I'm anywhere near trying to get me a glibc that will work on
both 680x0 hardware and CF v4e yet (still have to finish up binutils,
and start doing gcc after that), but it would help if I don't have to
merge too much code when I do get there.

[...]

--
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
In reply to this post by Richard Sandiford-3
Richard Sandiford <[hidden email]> writes:

> Andreas Schwab <[hidden email]> writes:
>> Richard Sandiford <[hidden email]> writes:
>>
>>>   - The canonical NaN has all significand bits set.
>>
>> This is not different to the 68881.  Since any non-zero bit pattern
>> qualifies as NaN that should not be a problem.
>
> Right, all nonzero significands do of course count as NaN.  But it
> depends what you mean by "problem".  I think it's worthwhile allowing
> users to assume that the NaNs of the same sign produced by one function
> will have the same bit pattern as NaNs produced by another.  In other
> words, it's a QoI issue.

I don't really like how it is implemented.  It depends on implementation
details of the shadowed files, which can change and silently break the
hack.  (Not that I expect it to change soon, but it already happened
once.)  I'd rather leave it alone.

> What were you thoughts on the rest of the patch?  Did it look
> OK otherwise?

How did you handle the lack of TLS support?

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:

> Richard Sandiford <[hidden email]> writes:
>> Andreas Schwab <[hidden email]> writes:
>>> Richard Sandiford <[hidden email]> writes:
>>>
>>>>   - The canonical NaN has all significand bits set.
>>>
>>> This is not different to the 68881.  Since any non-zero bit pattern
>>> qualifies as NaN that should not be a problem.
>>
>> Right, all nonzero significands do of course count as NaN.  But it
>> depends what you mean by "problem".  I think it's worthwhile allowing
>> users to assume that the NaNs of the same sign produced by one function
>> will have the same bit pattern as NaNs produced by another.  In other
>> words, it's a QoI issue.
>
> I don't really like how it is implemented.  It depends on implementation
> details of the shadowed files, which can change and silently break the
> hack.  (Not that I expect it to change soon, but it already happened
> once.)

Well, I agree it's not a nice implementation, but I think the only
clean fix would be to change upstream sources, and it's very unlikely
that any such changes would be accepted for the sake of m68k.
We're constrained by what would be allowed upstream.

Also, ports tend to need fairly regular TLC anyway if they're going to
keep pace with upstream changes.  The generic m68k changes are examples
of this.  I'm not sure these three files are any worse.  However...

> I'd rather leave it alone.

OK.  I've noted my objections, and it's your call to make.

>> What were you thoughts on the rest of the patch?  Did it look
>> OK otherwise?
>
> How did you handle the lack of TLS support?

A few local hacks to the libc/ tree, I'm afraid.  From that point of view,
you could argue that there's not much point applying the patch.  But the
same problem affects the current m68k port too, and I hope the patch is
strict improvement.

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Roman Zippel
In reply to this post by Richard Sandiford-3
Hi,

On Tuesday 15 August 2006 18:25, Richard Sandiford wrote:

>   - Coldfire strongly prefers a 32-bit aligned stack pointer, so I've
>     rounded frame sizes up to longword rather than word alignment.

m68k has maybe not a strong preference for longword alignment, but it would be
a good change for m68k as well.

bye, Roman
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Roman Zippel <[hidden email]> writes:
> On Tuesday 15 August 2006 18:25, Richard Sandiford wrote:
>>   - Coldfire strongly prefers a 32-bit aligned stack pointer, so I've
>>     rounded frame sizes up to longword rather than word alignment.
>
> m68k has maybe not a strong preference for longword alignment, but it
> would be a good change for m68k as well.

Sorry for not replying earlier.  I was waiting to see if Andreas
had any opinions on this.  For the record, I'm happy to make this
change if Andreas agrees.

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
In reply to this post by Richard Sandiford-3
This thread seems to have gone cold.  I think the only specific changes
that have been asked for so far are:

  - Remove the canonical NaN overrides.  [from Andreas]
  - Extend the longword frame size handling to m68k.  [from Roman]

I'm happy to make either or both changes, but wasn't sure what the
situation was.  If I make those changes, will the patch be OK to go in?

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Ping!

Richard Sandiford <[hidden email]> writes:

> This thread seems to have gone cold.  I think the only specific changes
> that have been asked for so far are:
>
>   - Remove the canonical NaN overrides.  [from Andreas]
>   - Extend the longword frame size handling to m68k.  [from Roman]
>
> I'm happy to make either or both changes, but wasn't sure what the
> situation was.  If I make those changes, will the patch be OK to go in?
>
> Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
In reply to this post by Richard Sandiford-3
Richard Sandiford <[hidden email]> writes:

> Andreas Schwab <[hidden email]> writes:
>> How did you handle the lack of TLS support?
>
> A few local hacks to the libc/ tree, I'm afraid.

That's the main reason I haven't bothered to check in any fixes for the
m68k port yet.

> From that point of view, you could argue that there's not much point
> applying the patch.  But the same problem affects the current m68k port
> too, and I hope the patch is strict improvement.

I agree.  Still it would be nice if we could develop a TLS ABI for the
m68k.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
In reply to this post by Richard Sandiford-3
Richard Sandiford <[hidden email]> writes:

> Sorry for not replying earlier.  I was waiting to see if Andreas
> had any opinions on this.  For the record, I'm happy to make this
> change if Andreas agrees.

Please go on.  And I'll promise to be more responsive in the future.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:
> Richard Sandiford <[hidden email]> writes:
>> Sorry for not replying earlier.  I was waiting to see if Andreas
>> had any opinions on this.  For the record, I'm happy to make this
>> change if Andreas agrees.
>
> Please go on.  And I'll promise to be more responsive in the future.

Thanks Andreas, and sorry for the slow reponse.  As luck would have it,
the test board I use became blocked with other things on the day I got
your reply.

Here's the revised patch.  The only differences are:

  - dl-trampoline.S now rounds up to longword alignment for m68k too.
  - There are no overrides for pow, sin and remainder.

Tested in the same way as before.

Richard


glibc-move.clog (8K) Download Attachment
glibc-move.sh (3K) Download Attachment
glibc.clog (4K) Download Attachment
glibc.diff (44K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
Richard Sandiford <[hidden email]> writes:

> @@ -79,15 +89,23 @@ _dl_runtime_profile:
>   move.l %sp, %a2
>   move.l %sp, %a0
>   lea 28(%sp), %a1
> - | Round framesize up to even
> - addq.l #1, %d1
> - lsr #1, %d1
> - sub.l %d1, %a0
> + | Round framesize up to longword alignment
> + addq.l #3, %d1
> + and.l #-3, %d1
>   sub.l %d1, %a0
>   move.l %a0, %sp
> +#ifdef __mcoldfire__
> + tst.l %d1
> + beq 2f
> +1: move.l (%a0)+, (%a1)+
> + subq.l #4,%d1
> + bne 1b
> +2:
> +#else
>   jra 2f
>  1: move.w (%a1)+, (%a0)+
>  2: dbra %d1,1b
> +#endif

This is wrong, the !__mcoldfire__ case now copies twice as much.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:

> Richard Sandiford <[hidden email]> writes:
>
>> @@ -79,15 +89,23 @@ _dl_runtime_profile:
>>   move.l %sp, %a2
>>   move.l %sp, %a0
>>   lea 28(%sp), %a1
>> - | Round framesize up to even
>> - addq.l #1, %d1
>> - lsr #1, %d1
>> - sub.l %d1, %a0
>> + | Round framesize up to longword alignment
>> + addq.l #3, %d1
>> + and.l #-3, %d1
>>   sub.l %d1, %a0
>>   move.l %a0, %sp
>> +#ifdef __mcoldfire__
>> + tst.l %d1
>> + beq 2f
>> +1: move.l (%a0)+, (%a1)+
>> + subq.l #4,%d1
>> + bne 1b
>> +2:
>> +#else
>>   jra 2f
>>  1: move.w (%a1)+, (%a0)+
>>  2: dbra %d1,1b
>> +#endif
>
> This is wrong, the !__mcoldfire__ case now copies twice as much.

Gah!  You're right of course.  Is it OK with the move.w changed
into a move.l?  If so, do you want me to refresh the patch, or would
it be easier for you to just edit it locally?

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
Richard Sandiford <[hidden email]> writes:

> Gah!  You're right of course.  Is it OK with the move.w changed
> into a move.l?

Yes, please.  Since the size is now a multiple of 4 bytes, this will work
now.

> If so, do you want me to refresh the patch, or would
> it be easier for you to just edit it locally?

Please prepare an incremental patch, I'll merge them.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:

> Richard Sandiford <[hidden email]> writes:
>> Gah!  You're right of course.  Is it OK with the move.w changed
>> into a move.l?
>
> Yes, please.  Since the size is now a multiple of 4 bytes, this will work
> now.
>
>> If so, do you want me to refresh the patch, or would
>> it be easier for you to just edit it locally?
>
> Please prepare an incremental patch, I'll merge them.

OK, thanks, here's the patch.  Hope I got it right this time.
I haven't included a changelog because it comes under the
change described in the original changelog.

Richard


--- glibc-head/ports/sysdeps/m68k/dl-trampoline.S 2006-10-03 02:43:59.180573000 -0700
+++ glibc-head/ports/sysdeps/m68k/dl-trampoline.S 2006-10-03 02:45:42.342370000 -0700
@@ -102,8 +102,9 @@
  bne 1b
 2:
 #else
+ lsr.l #2,%d1
  jra 2f
-1: move.w (%a1)+, (%a0)+
+1: move.l (%a1)+, (%a0)+
 2: dbra %d1,1b
 #endif
  /*
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Andreas Schwab
Richard Sandiford <[hidden email]> writes:

> OK, thanks, here's the patch.  Hope I got it right this time.
> I haven't included a changelog because it comes under the
> change described in the original changelog.

Thanks alot for your efforts.  I have now checked in your changes, except
for the linuxthreads part (where I don't have commit rights).  Daniel,
could you please check in the linuxthread parts in
<http://sourceware.org/ml/libc-ports/2006-08/msg00016.html>?

Thanks, Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Richard Sandiford-3
Andreas Schwab <[hidden email]> writes:
> Richard Sandiford <[hidden email]> writes:
>> OK, thanks, here's the patch.  Hope I got it right this time.
>> I haven't included a changelog because it comes under the
>> change described in the original changelog.
>
> Thanks alot for your efforts.  I have now checked in your changes, except
> for the linuxthreads part (where I don't have commit rights).

Thanks Andreas!  And thanks for your patience during the whole process.

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Porting glibc to Coldfire

Daniel Jacobowitz-2
In reply to this post by Andreas Schwab
On Tue, Oct 03, 2006 at 05:08:39PM +0200, Andreas Schwab wrote:

> Richard Sandiford <[hidden email]> writes:
>
> > OK, thanks, here's the patch.  Hope I got it right this time.
> > I haven't included a changelog because it comes under the
> > change described in the original changelog.
>
> Thanks alot for your efforts.  I have now checked in your changes, except
> for the linuxthreads part (where I don't have commit rights).  Daniel,
> could you please check in the linuxthread parts in
> <http://sourceware.org/ml/libc-ports/2006-08/msg00016.html>?

Done!

--
Daniel Jacobowitz
CodeSourcery