uClibc-alpine/libc/sysdeps/linux/frv/sys, branch master Where we track our uclibc patches Alexandre Oliva writes: 2004-05-14T10:59:09+00:00 Eric Andersen andersen@codepoet.org 2004-05-14T10:59:09+00:00 297b6bb585320c9ee650258fb3d3e7e812cdc5a8 Here are a number of minor changes to FR-V-specific bits of the uClibc port: - I've adjusted the definition of _dl_mmap to cope with the fact that there will be a definition for an mmap2-only system. - We don't have COPY relocs, so optimize the copy reloc-related code away. - Change the page size to 16KiB, to match the ABI spec, and not a stale value I'd copied from a linker config file. Oops. - Fix error handling in clone and vfork; parts of the changes by David Howells <dhowells@redhat.com> - Rearrange includes in crtreloc.c. - Change the API of __syscall_error, to reduce code size. - Improve __syscall_return in terms of code size, so as to enable tail-calling of __syscall_error, at least within libc. Ideally, __syscall_error should be hidden within libc.so, but this didn't work because of libdl. I haven't looked into why, and figured I'd leave it visible for now. - Rename enumerators and macros in sys/ucontext.h to reduce namespace pollution. 
Here are a number of minor changes to FR-V-specific bits of the uClibc
port:

- I've adjusted the definition of _dl_mmap to cope with the fact that
  there will be a definition for an mmap2-only system.

- We don't have COPY relocs, so optimize the copy reloc-related code
  away.

- Change the page size to 16KiB, to match the ABI spec, and not a
  stale value I'd copied from a linker config file.  Oops.

- Fix error handling in clone and vfork; parts of the changes by David
  Howells <dhowells@redhat.com>

- Rearrange includes in crtreloc.c.

- Change the API of __syscall_error, to reduce code size.

- Improve __syscall_return in terms of code size, so as to enable
  tail-calling of __syscall_error, at least within libc.  Ideally,
  __syscall_error should be hidden within libc.so, but this didn't
  work because of libdl.  I haven't looked into why, and figured I'd
  leave it visible for now.

- Rename enumerators and macros in sys/ucontext.h to reduce namespace
  pollution.
Alexandre Oliva writes: 2004-02-18T08:04:51+00:00 Eric Andersen andersen@codepoet.org 2004-02-18T08:04:51+00:00 baa67289df42b1b994092b8312148a6f9e172274 This patch adds code to uClibc to support a new ABI designed for the FR-V architecture, that enables text segments of executables and shared libraries to be shared by multiple processes on an OS such as uClinux, that can run on FR-V processors without an MMU. Patches for binutils and GCC have just been posted in the corresponding mailing lists. The binutils patch was approved, but there's one additional patch pending review, that I posted this week. An updated GCC patch will be posted to gcc-patches@gcc.gnu.org as soon as I complete testing (I used a known-good compiler to test the uClibc patch below). Since the existing dynamic loader code didn't support independent relocation of segments, it required changes that were somewhat extensive. I've added a number of new machine-specific macros to try to keep the platform and ABI-specific details outside the generic code. I hope this is not a problem. 
This patch adds code to uClibc to support a new ABI designed for the
FR-V architecture, that enables text segments of executables and
shared libraries to be shared by multiple processes on an OS such as
uClinux, that can run on FR-V processors without an MMU.

Patches for binutils and GCC have just been posted in the
corresponding mailing lists.  The binutils patch was approved,
but there's one additional patch pending review, that I posted
this week.  An updated GCC patch will be posted to
gcc-patches@gcc.gnu.org as soon as I complete testing (I used a
known-good compiler to test the uClibc patch below).

Since the existing dynamic loader code didn't support independent
relocation of segments, it required changes that were somewhat
extensive.  I've added a number of new machine-specific macros to try
to keep the platform and ABI-specific details outside the generic
code.  I hope this is not a problem.