| Age | Commit message (Collapse) | Author |
|---|
|
|
|
[peter.kjellerstedt@axis.com]
Peter Kellerstedt writes:
May I suggest the attached patch instead?
It handles PICFLAG the same way as it was already done
for other architectures (e.g., CRIS and frv).
|
|
This patch makes -fpic work for PCC and optimzes the relcation by moving the cache
flushing stuff to JMP relocs only. Actually PPCs ldso can only handle small
GOT tables(<=8192 entries)anyhow, so it makes little sense to compile PPC with -fPIC.
libuClibc shrunk from 340724 to 330780 bytes with -fpic.
|
|
won't be needed for 3.3.4 either when I get some time to clean up that
toolchain which also suffers from the g++ include dir search order bug.
|
|
about the best settings the AMD Elan and the VIA Nehemiah.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Makefiles ignore CFLAGS.
|
|
Also try to make sure the build breaks if we want soft float but
don't know how to request it.
|
|
|
|
|
|
|
|
|
|
around...
|
|
|
|
places....
|
|
|
|
which should simplify enabling arbitrary architectures.
-Erik
|
|
|
|
Remove the ADD_LIBGCC_FUNCTIONS option and do things the right way.
Either we have a shared libgcc available, or the libgcc routines
aren't PIC and don't belong in the shared libc anyway.
|
|
|
|
|
|
ln.patch:
* Define $(LN) as ln in Rules.mak.
* Change all occurrences of ln into $(LN).
* Change all constructs like (cd path && ln -sf foo/file file)
into $(LN) -sf foo/file path/file. The latter construct is
already used in a number of places so it should not be
an additional compatibility problem.
|
|
rm.patch:
* Define $(RM) as rm -f in Rules.mak and test/Rules.mak
(this is the same definition as gmake uses by default).
* Change all occurrences of rm and rm -f into $(RM).
|
|
install.patch:
* Define $(INSTALL) as install in Rules.mak.
* Change all occurrences of install into $(INSTALL).
* Change all occurrences of mkdir -p into $(INSTALL) -d.
install -d is already used in a number of places so
this should not be an additional compatibility problem.
|
|
|
|
|
|
|
|
|
|
|
|
Here's a patch that implements the beginnings of a rudimentary sh64 port. So
far, this only works static, as I haven't done any of the ldso work yet. I've
also not touched the libpthread stuff yet either, so that's also disabled for
now.
This port was based off of some work that Sean McGoogan at SuperH did for his
initial port, but the this patch doesn't carry over too much from there
(basically the libc/sysdeps/linux/sh64/Makefile (or rather, parts of it),
the setjmp/longjmp stuff (which I had to rewrite portions of it to work with
the new toolchains), etc.).
However, for static, everything appears to work correcly, at least in a hello
world type application.
|
|
either -fPIC or -fpic
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-Erik
|
|
x86 compiler optimization to not force building i386 opcodes.
|
|
enforce consistent sort order, 'gcc -print-search-dirs'
behavior, etc by forcing the build into the C locale.
-Erik
|
|
patch from Stefan Allius (though the extra/config/Makefile
rework is mine),
-Erik
|
|
|
