Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nwangjiahui <wangjiahui27@huawei.com>

Signed-off-by: Nmaweiye <maweiye@huawei.com>

Signed-off-by: Nyangwenjun <yangwenjun13@huawei.com>

This reverts commit fd8c6da6, reversing
changes made to acdab8e8.
Signed-off-by: Nyangwenjun <yangwenjun13@huawei.com>

close: #I53KTP
Signed-off-by: Nzff <zhangfanfan2@huawei.com>

Revert "!268 Dynamic linker supports namespace mechanism"

This reverts commit acdab8e8, reversing
changes made to 412ca9eb.
Signed-off-by: Njiangkuaixue <jiangchenzhou@huawei.com>

Signed-off-by: Nyangwenjun <yangwenjun13@huawei.com>

Signed-off-by: Nmaweiye <maweiye@huawei.com>

Signed-off-by: Nyangwenjun <yangwenjun13@huawei.com>

Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: I299fd0210b7baa081a98ed1655bae06fd45173e8

Signed-off-by: Nhhj <huanghuijin@huawei.com>

Signed-off-by: Nhuanghuijin <huanghuijin@huawei.com>

Signed-off-by: Ncaifuzhou <caifuzhou@huawei.com>

isolate changes, keep orignal musl sources clean.
Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: Id7f3a5109771f93d397e30febba36e09ddaf4f36

Description:opt open lib speed when dlopen and exec
Team:OTHERS
Feature or Bugfix:Bugfix
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: I06512e283b7d04e45b33b6c6665230f90d99ace0
Reviewed-on: http://mgit-tm.rnd.huawei.com/10544035Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nlihao 00517597 <lihao189@huawei.com>
Reviewed-by: Nchenwei 00346986 <chenwei26@huawei.com>
Reviewed-by: Nzhengzhou 00427224 <zhengzhou8@huawei.com>
Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>

This reverts commit b96246c5.

Change-Id: Ica8da9e977b05625aa4f3173e5e42a97a49d8e60
Reviewed-on: http://mgit-tm.rnd.huawei.com/10360347Reviewed-by: Nliulei 00510663 <lewis.liulei@huawei.com>
Reviewed-by: Nlihao 00517597 <lihao189@huawei.com>
Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nzhaopeng 00380337 <zhaopeng22@huawei.com>

Description:add a private flag to mark an elf file, and remove obsolete cached pages before writing on a elf file

Team:OTHERS
Feature or Bugfix:Bugfix
Binary Source:NA
PrivateCode(Yes/No):No

Change-Id: If3a17ac05c5035045704a0b66307165ab0076c34
Reviewed-on: http://mgit-tm.rnd.huawei.com/10334851Reviewed-by: Ncaoruihong 00546070 <crh.cao@huawei.com>
Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>
Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>

Description:userspace musl code

Team:OTHERS
Feature or Bugfix:Feature
Binary Source:NA
PrivateCode(Yes/No):No

Change-Id: I1d445ef7d16285be98b1857f4c01b94c9759daea
Reviewed-on: http://mgit-tm.rnd.huawei.com/10274931Reviewed-by: Ncaoruihong 00546070 <crh.cao@huawei.com>
Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>

the bug fixed in commit b82cd6c7 was
mostly masked on arm because __hwcap was zero at the point of the call
from the dynamic linker to __set_thread_area, causing the access to
libc.auxv to be skipped and kuser_helper versions of TLS access and
atomics to be used instead of the armv6 or v7 versions. however, on
kernels with kuser_helper removed for hardening it would crash.

since __set_thread_area potentially uses __hwcap, it must be
initialized before the function is called. move the AT_HWCAP lookup
from stage 3 to stage 2b.

at least gcc 9 broke execution of DT_INIT/DT_FINI for fdpic archs
(presently only sh) by recognizing that the stores to the
compound-literal function descriptor constructed to call them were
dead stores. there's no way to make a "may_alias function", so instead
launder the descriptor through an asm-statement barrier. in practice
just making the compound literal volatile seemed to have worked too,
but this should be less of a hack and more accurately convey the
semantics of what transformations are not valid.

commit 1c84c999 moved the call to
__init_tp above the initialization of libc.auxv, inadvertently
breaking archs where __set_thread_area examines auxv for the sake of
determining the TLS/atomic model needed at runtime. this broke armv6
and sh2.

this interface contract is entirely internal to dynlink.c.

if symbols are being redirected to provide the new time64 ABI, dlsym
must perform matching redirections; otherwise, it would poke a hole in
the magic and return pointers to functions that are not safe to call
from a caller using time64 types.

rather than duplicating a table of redirections, use the time64
symbols present in libc's symbol table to derive the decision for
whether a particular symbol needs to be redirected.

commit ffab4360 broke this by moving
relocations after not only the allocation of storage for the main
thread's static TLS, but after the copying of the TLS image. thus,
relocation results were not reflected in the main thread's copy. this
could be fixed by calling __reset_tls after relocations, but instead
split the allocation and installation before/after relocations so that
there's not a redundant copy.

due to commit 71af5309, updating of
static_tls_cnt needs to be kept with allocation of static TLS, before
relocations, rather than after installation.

Using common code path for all symbol lookups fixes three dlsym issues:

- st_shndx of STT_TLS symbols were not checked and thus an undefined
  tls symbol reference could be incorrectly treated as a definition
  (the sysv hash lookup returns undefined symbols, gnu does not, so should
  be rare in practice).

- symbol binding was not checked so a hidden symbol may be returned
  (in principle STB_LOCAL symbols may appear in the dynamic symbol table
  for hidden symbols, but linkers most likely don't produce it).

- mips specific behaviour was not applied (ARCH_SYM_REJECT_UND) so
  undefined symbols may be returned on mips.

always_inline is used to avoid relocation performance regression, the
code generation for find_sym should not be affected.

commit 7a9669e9 added use of the
symbol reference as the definition, in place of performing a lookup,
for STT_SECTION symbol references that were first found used in FDPIC.
such references may happen in certain other cases, such as
local-dynamic TLS and with relocation types that require a symbol but
that are being used for non-symbolic purposes, like the powerpc
unaligned address relocations.

in all such cases I'm aware of, the symbol referenced is a section
symbol (STT_SECTION); however, the important semantic property is not
its being a section, but rather its binding local (STB_LOCAL). check
the latter instead of the former for greater generality and semantic
correctness.

R_PPC_UADDR32 (R_PPC64_UADDR64) has the same meaning as R_PPC_ADDR32
(R_PPC64_ADDR64), except that its address need not be aligned. For
powerpc64, BFD ld(1) will automatically convert between ADDR<->UADDR
relocations when the address is/isn't at its native alignment. This
will happen if, for example, there is a pointer in a packed struct.

gold and lld do not currently generate R_PPC64_UADDR64, but pass
through misaligned R_PPC64_ADDR64 relocations from object files,
possibly relaxing them to misaligned R_PPC64_RELATIVE. In both cases
(relaxed or not) this violates the PSABI, which defines the relevant
field type as "a 64-bit field occupying 8 bytes, the alignment of
which is 8 bytes unless otherwise specified."

All three linkers violate the PSABI on 32-bit powerpc, where the only
difference is that the field is 32 bits wide, aligned to 4 bytes.

Currently musl fails to load executables linked by BFD ld containing
R_PPC64_UADDR64, with the error "unsupported relocation type 43".
This change provides compatibility with BFD ld on powerpc64, and any
static linker on either architecture that starts following the PSABI
more closely.

as a result of commit ffab4360,
static_tls_cnt is now valid during relocations at program startup, so
it's no longer necessary to condition the check against static_tls_cnt
on this being a runtime (dlopen) relocation.

this is analogous to commit 2f1f51ae,
and should have been caught at the same time since it was right next
to the code moved in that commit. between final stage 3 reloc_all and
the jump to the main program's entry point, it is not valid to call
any functions which may be interposed by the application; doing so
results in execution of application code before ctors have run, and on
fdpic archs, before the main program's fdpic self-fixups have taken
place, which will produce runaway wrong execution.

commit c8b49b2f introduced code that
checked bestsym to determine whether a matching symbol was found, but
bestsym is uninitialized if not. instead use best, consistent with use
in the rest of the function.

simplified from bug report and patch by Cheng Liu.

after commit a48ccc15 removed the use
of _Noreturn on the stage3_func type (which only worked due to it
being defined to the "GNU C" attribute in C99 mode), GCC could no
longer assume that the ends of __dls2 and __dls2b are unreachable, and
produced a warning that a function marked _Noreturn returns.

also, since commit 4390383b, the
_Noreturn declaration for __libc_start_main in crt1/rcrt1 has been not
only inconsistent with the definition, but wrong. formally,
__libc_start_main does return, via a (hopefully) tail call to a helper
function after the barrier. incorrect usage of _Noreturn in the
declaration was probably formal UB.

the _Noreturn specifiers were not useful in any of these places, so
remove them all. now, the only remaining usage of _Noreturn is in
public interfaces where _Noreturn is part of their contract.

currently the bfd linker does not seem to create tls segments where
p_vaddr%p_align != 0, but this is valid in ELF and then the runtime
computed tls offset must satisfy

  offset%p_align == (base+p_vaddr)%p_align

and in case of local exec tls (main executable) the smallest such
offset must be used (otherwise it is incompatible with the offset
computed by the static linker). the !TLS_ABOVE_TP case is handled
correctly (the offset is negative then in the formula).

the ldso code for TLS_ABOVE_TP is changed so the static tls offset
of each module satisfies the formula.

tls_offset should always point to the end of the allocated static tls
area, but this was not handled correctly on "tls variant 1" targets
in the dynamic linker:

after application tls was allocated, tls_offset was aligned up,
potentially wasting tls space. (alignment may be needed at the
begining of the tls area, not at the end, but that will be fixed
separately as it is unlikely to affect real binaries.)

when static tls was allocated for a shared library, tls_offset was
only updated with the size of the tls segment which does not include
alignment gaps, which can easily happen if the tls size update for
one library leaves tls_offset misaligned for the next one. this can
cause oob access in __copy_tls or arbitrary breakage at tls access.
(the issue was observed on aarch64 with rust binaries)

maintainer's note: commit 9d44b646
removed their use.

this is the first part of a series of patches intended to make
__syscall fully self-contained in the object file produced using
syscall.h, which will make it possible for crt1 code to perform
syscalls.

the (confusingly named) i386 __vsyscall mechanism, which this commit
removes, was introduced before the presence of a valid thread pointer
was mandatory; back then the thread pointer was setup lazily only if
threads were used. the intent was to be able to perform syscalls using
the kernel's fast entry point in the VDSO, which can use the sysenter
(Intel) or syscall (AMD) instruction instead of int $128, but without
inlining an access to the __syscall global at the point of each
syscall, which would incur a significant size cost from PIC setup
everywhere. the mechanism also shuffled registers/calling convention
around to avoid spills of call-saved registers, and to avoid
allocating ebx or ebp via asm constraints, since there are plenty of
broken-but-supported compiler versions which are incapable of
allocating ebx with -fPIC or ebp with -fno-omit-frame-pointer.

the new mechanism preserves the properties of avoiding spills and
avoiding allocation of ebx/ebp in constraints, but does it inline,
using some fairly simple register shuffling, and uses a field of the
thread structure rather than global data for the vdso-provided syscall
code address.

for now, the external __syscall function is refactored not to use the
old __vsyscall so it can be kept, but the intent is to remove it too.