Age | Commit message (Collapse) | Author |
|
in various places defined(__arm__) is used to protect/select code which
is ARM specific, that code must also be selected for __thumb__ because
__thumb__ is an ARM but __arm__ is not set...
|
|
|
|
|
|
|
|
|
|
|
|
load_addr) which are computer later
|
|
|
|
|
|
|
|
|
|
|
|
optimization level chosen. This allows uClibc to be compiled with the
latest GCC-4.1.0. While tracking down the specific culprit causing
the segmentation fault of the dynamic loader with GCC-4.1.0 I was
able to force inlining of other functions such that I shaved 512 bytes
off the size of the loader, yay. Also fixed warning in 'dl-hash.c'.
|
|
|
|
|
|
|
|
works at all, so disable the whole lot.
|
|
|
|
significantly less horrible
|
|
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,
|
|
Other arches may also benefit from this iff it can do
unaligned stores.
|
|
|
|
_dl_strchr,_dl_strrchr,_dl_strstr,_dl_memcmp:
Optimize for archs which can do pre increment/decrement and load/store
in one instruction.
|
|
handle "" strings and optimze it.
_dl_simple_ltoa,_dl_simple_ltoahex:
Optimize for archs which can do pre increment/decrement and load/store
in one instruction.
|
|
dl-string.h references do_rem, but do_rem is a #define in <arch>/dl-sysdep.h
which is not included by dl-sysdep.h. This causes a problem in libdl:
In file included from ../../ldso/include/ldso.h:27, from libdl.c:33:
../../ldso/include/dl-string.h: In function `_dl_simple_ltoa':
../../ldso/include/dl-string.h:216: warning: implicit declaration of
function `do_rem'
Include dl-sysdep.h in dl-string.h before using do_rem.
|
|
Hello,
I managed to get ldso (and thus shared linking to uClibc) to work on
sparc (actually sparc64 kernel with 32-bit userspace), at least on
simple "hello world" program (more complex ones not tested).
Some notes on attached patch (against 0.9.26, would require some work
to apply on current CVS - but I tested 0.9.26, not CVS):
- ELF magic cannot be examined by _dl_strncmp so early, probably because of
string constant, like on ppc/mips/sh
(note that early SEND_STDERR still crashes when trying to do _dl_strlen
- I suppose that string constants require relocation; but adding
load_addr didn't help, just ELF header was displayed instead of crash)
- mmap() is syscall6 like on ppc/mips/sh, not old i386 mmap()
- for generic sparc (i.e. not sparcv8/sparcv9) gcc produces .udiv/.urem
calls for unsigned integer / and % operators - so these operations
must be avoided. I copied do_rem definition from arm header.
But / and % are used also in _dl_simple_ltoa() and
_dl_simple_ltoahex(); in ltoahex gcc optimizes it to shifts (but
I think it's safer to use shifts explicitly, not rely on
optimization...).
I changed % in ltoa to do_rem, but as there was no do_div definition,
I changed all "%d" specifiers to "%x" to avoid crashes (this changes
wouldn't be needed if _dl_simple_ltoa() were fixed to not use
division on sparc).
- "#define SOLARIS_COMPATIBLE" in ld_sysdep.h broke ldso on Linux
because of redefining _dl_linux_resolve only in some places (it was
still referenced in INIT_GOT before redefinition). So
_dl_linux_resolve redefinition should be moved before INIT_GOT
definition or removed.
- sparc64 kernel requires mmap() addresses to be aligned to 8192, not
4096, otherwise mmap() call failed
- reloc_entry must be shifted by 10, not 12 (I found similar operation
in glibc sources)
Aside of sparc-specific fixes:
- I moved some _dl_dprintf()s inside if(_dl_debug_*) conditions (to avoid
debugging messages when LD_DEBUG is not defined)
- it seems that there was possible off-by-one in ltoa and ltoahex?
they are called with char[22] as 1st argument, and then '\0' is stored
in local[22] (_before_ p decrementation)... or am I missing something?
If not, fix is included in patch.
|
|
|
|
|
|
|
|
|