summaryrefslogtreecommitdiff
path: root/src/signal/sigtimedwait.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2015-05-25 23:33:59 -0400
committerRich Felker <dalias@aerifal.cx>2015-05-25 23:33:59 -0400
commit9bbddf730f7837cf87f4c789fbb41a312e295d6c (patch)
tree4cd6c478aa82397eca1868f0079ac48ad4853613 /src/signal/sigtimedwait.c
parent768b82c6de24e480267c4c251c440edfc71800e3 (diff)
downloadmusl-9bbddf730f7837cf87f4c789fbb41a312e295d6c.tar.gz
reprocess all libc/ldso symbolic relocations in dynamic linking stage 3
commit f3ddd173806fd5c60b3f034528ca24542aecc5b9 introduced early relocations and subsequent reprocessing as part of the dynamic linker bootstrap overhaul, to allow use of arbitrary libc functions before the main application and libraries are loaded, but only reprocessed GOT/PLT relocation types. commit c093e2e8201524db0d638920e76bcb6b1d925f3a added reprocessing of non-GOT/PLT relocations to fix an actual regression that was observed on powerpc, but only for RELA format tables with out-of-line addends. REL table (inline addends at the relocation address) reprocessing is trickier because the first relocation pass clobbers the addends. this patch extends symbolic relocation reprocessing for libc/ldso to support all relocation types, whether REL or RELA format tables are used. it is believed not to alter behavior on any existing archs for the current dynamic linker and libc code. the motivations for this change are consistency and future-proofing. it ensures that behavior does not differ depending on whether REL or RELA tables are used, which could lead to undetected arch-specific bugs. it also ensures that, if in the future code depending on additional relocation types is added to libc.so, either at the source level or as part of the compiler runtime that gets pulled in (for example, soft-float with TLS for fenv), the new code will work properly. the implementation concept is simple: stage 2 of the dynamic linker counts the number of symbolic relocations in the libc/ldso REL table and allocates a VLA to save their addends into; stage 3 then uses the saved addends in place of the inline ones which were clobbered. for stack safety, a hard limit (currently 4k) is imposed on the number of such addends; this should be a couple orders of magnitude larger than the actual need. this number is not a runtime variable that could break fail-safety; it is constant for a given libc.so build.
Diffstat (limited to 'src/signal/sigtimedwait.c')
0 files changed, 0 insertions, 0 deletions