| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
as the flags for all calls to 'as'
|
|
Here's an updated version of the patch I posted about a month ago. It
leaves -nostdinc alone, and uses -print-file-name=include instead of
-print-search-dirs to figure out where GCC's internal headers are.
Please let me know whether there are any portions of this patch you'd
like me to break into smaller pieces, to rework, or to give up trying
to get into uClibc :-) Thanks,
|
|
The attached patch generalizes the use of PIE (all archs are brought in
sync that use/mention it: x86/ppc/frv) and makes use of it building the
target utils.
Tested on x86, ppc should be tested, frv uses -fPIE at one location, but
at another place -fpie, I don't know which is correct (could be both) and
misses the target addition in Config.in.
The test for ppc (requires the earlier sent crt-correction patch to work
correctly):
enable UCLIBC_PIE_SUPPORT, build uClibc and utils, check:
file ./utils/ldd, it should show shared object (instead of executable)
|
|
- adjust licensing terms of sources for crt*.o
- change the stat ABI to speed it up, matching changes in the kernel
- assorted bug-fixes, improvements and updates in the FR-V port
etc.
|
|
size and performance penalty to profiling applications this way, as well as
Heisenberg effects, where the act of measuring changes what is measured.
There are better tools for doing profiling, such as OProfile, that do not
require gcc to instrument the application code.
-Erik
|
|
Some utilities, such as valgrind, have a legitimate reason to know the address
of the current brk. Since we know such utils will peek under our skirt, we
might as well give them what they expect and not use a gratuitously different
symbol name.
-Erik
|
|
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.
|
|
have it. It is used by the boehm gc, amoung other things.
|
|
|
|
On Mar 20, 2004, Erik Andersen <andersen@codepoet.org> wrote:
> If you supply a FR-V specific link.h header into
> libc/sysdeps/linux/frv/ then you can do the same sortof
> thing that mips does i.e. with sgidefs.h in the headers
> target in libc/sysdeps/linux/mips/Makefile
Thanks, this patch implements your suggestion.
|
|
I added this function after I posted the last version of the FR-V
patch. Add syscall.c.
|
|
the symbol in common.
|
|
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.
|
