| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
these files are all accepted as legacy arm syntax when producing arm
code, but legacy syntax cannot be used for producing thumb2 with
access to the full ISA. even after switching to UAL, some asm source
files contain instructions which are not valid in thumb mode, so these
will need to be addressed separately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the idea of the three-instruction sequence being removed was to be
able to return to thumb code when used on armv4t+ from a thumb caller,
but also to be able to run on armv4 without the bx instruction
available (in which case the low bit of lr would always be 0).
however, without compiler support for generating such a sequence from
C code, which does not exist and which there is unlikely to be
interest in implementing, there is little point in having it in the
asm, and it would likely be easier to add pre-armv4t support via
enhanced linker handling of R_ARM_V4BX than at the compiler level.
removing this code simplifies adding support for building libc in
thumb2-only form (for cortex-m).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
since commit c5e34dabbb47d8e97a4deccbb421e0cd93c0094b, crt1.c has
provided a "mostly-C" implementation of the crt1 start file that
avoids the need for arch-specific symbol referencing, PIC/PIE-specific
code variants, etc. but for archs that had existing hand-written
versions, the new code was initially unused, and later only used as
the dynamic linker entry point. this commit switches all archs to
using the new code.
the code being removed was a recurring source of subtle errors, and
was still broken at least on arm, where it failed to properly align
the stack pointer before calling into C code.
|
| |
|
|
|
|
|
|
|
| |
without these, calls may be resolved incorrectly if the calling code
has been compiled to thumb instead of arm. it's not clear to me at
this point whether crt_arch.h is even working if crt1.c is built as
thumb; this needs testing. but the _init and _fini issues were known
to cause crashes in static-linked apps when libc was built as thumb,
and this commit should fix that issue.
|
| |
|
|
|
| |
this code has been replaced by portable C code that works on all
archs. the old asm needs to be removed or ctors/dtors will run twice.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
a while back, gcc switched from using the old _init/_fini fragments
method for calling ctors and dtors on arm to the __init_array and
__fini_array method. unfortunately, on glibc this depends on ugly
hacks involving making libc.so a linker script and pulling parts of
libc into the main program binary. so I cheat a little bit, and just
write asm to iterate over the init/fini arrays from the _init/_fini
asm. the same approach could be used on any arch it's needed on, but
for now arm is the only one.
|
| |
|
|
|
|
|
| |
lr must be saved because init/fini-section code from the compiler
clobbers it. this was not a problem when i tested without gcc's
crtbegin/crtend files present, but with them, musl on arm fails to
work (infinite loop in _init).
|
| |
|
|
|
|
|
|
|
|
| |
this is mainly in hopes of supporting c++ (not yet possible for other
reasons) but will also help applications/libraries which use (and more
often, abuse) the gcc __attribute__((__constructor__)) feature in "C"
code.
x86_64 and arm versions of the new startup asm are untested and may
have minor problems.
|
|
|
this port assumes eabi calling conventions, eabi linux syscall
convention, and presence of the kernel helpers at 0xffff0f?0 needed
for threads support. otherwise it makes very few assumptions, and the
code should work even on armv4 without thumb support, as well as on
systems with thumb interworking. the bits headers declare this a
little endian system, but as far as i can tell the code should work
equally well on big endian.
some small details are probably broken; so far, testing has been
limited to qemu/aboriginal linux.
|
