| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | remove additional libc struct accessor cruft•••commit f9cccfc16e58b39ee381fbdfb8688db3bb8e3555 left behind the part
in libc.c; remove it too.
| Rich Felker | 2015-04-22 | 1 | -12/+0 |
| * | add support for program_invocation[_short]_name•••this is a bit ugly, and the motivation for supporting it is
questionable. however the main factors were:
1. it will be useful to have this for certain internal purposes
anyway -- things like syslog.
2. applications can just save argv[0] in main, but it's hard to fix
non-portable library code that's depending on being able to get the
invocation name without the main application's help.
| Rich Felker | 2013-04-06 | 1 | -0/+4 |
| * | i386 vsyscall support (vdso-provided sysenter/syscall instruction based)•••this doubles the performance of the fastest syscalls on the atom I
tested it on; improvement is reportedly much more dramatic on
worst-case cpus. cannot be used for cancellable syscalls.
| Rich Felker | 2012-10-11 | 1 | -0/+1 |
| * | save AT_HWCAP from auxv for subsequent use in machine-specific code•••it's expected that this will be needed/useful only in asm, so I've
given it its own symbol that can be addressed in pc-relative ways from
asm rather than adding a field in the __libc structure which would
require hard-coding the offset wherever it's used.
| Rich Felker | 2012-07-27 | 1 | -0/+2 |
| * | new attempt at working around the gcc 3 visibility bug•••since gcc is failing to generate the necessary ".hidden" directive in
the output asm, generate it explicitly with an __asm__ statement...
| Rich Felker | 2012-02-24 | 1 | -0/+4 |
| * | remove useless attribute visibility from definitions•••this was a failed attempt at working around the gcc 3 visibility bug
affecting x86_64. subsequent patch will address it with an ugly but
working hack.
| Rich Felker | 2012-02-24 | 1 | -1/+1 |
| * | cleanup and work around visibility bug in gcc 3 that affects x86_64•••in gcc 3, the visibility attribute must be placed on both the
declaration and on the definition. if it's omitted from the
definition, the compiler fails to emit the ".hidden" directive in the
assembly, and the linker will either generate textrels (if supported,
such as on i386) or refuse to link (on targets where certain types of
textrels are forbidden or impossible without further assumptions about
memory layout, such as on x86_64).
this patch also unifies the decision about when to use visibility into
libc.h and makes the visibility in the utf-8 state machine tables
based on libc.h rather than a duplicate test.
| Rich Felker | 2012-02-23 | 1 | -1/+1 |
| * | various changes in preparation for dynamic linking support•••prefer using visibility=hidden for __libc internal data, rather than
an accessor function, if the compiler has visibility.
optimize with -O3 for PIC targets (shared library). without heavy
inlining, reloading the GOT register in small functions kills
performance. 20-30% size increase for a single libc.so is not a big
deal, compared to comparaible size increase in every static binaries.
use -Bsymbolic-functions, not -Bsymbolic. global variables are subject
to COPY relocations, and thus binding their addresses in the library
at link time will cause library functions to read the wrong (original)
copies instead of the copies made in the main program's bss section.
add entry point, _start, for dynamic linker.
| Rich Felker | 2011-02-24 | 1 | -1/+1 |
| * | use an accessor function for __libc data pointer when compiled as PIC•••prior to this change, a large portion of libc was unusable prior to
relocation by the dynamic linker, due to dependence on the global data
in the __libc structure and the need to obtain its address through the
GOT. with this patch, the accessor function __libc_loc is now able to
obtain the address of __libc via PC-relative addressing without using
the GOT. this means the majority of libc functionality is now
accessible right away.
naturally, the above statements all depend on having an architecture
where PC-relative addressing and jumps/calls are feasible, and a
compiler that generates the appropriate code.
| Rich Felker | 2011-02-20 | 1 | -1/+9 |
| * | initial check-in, version 0.5.0 | Rich Felker | 2011-02-12 | 1 | -0/+3 |
