runtime_loader: accept type STT_FUNC when STT_OBJECT is requested

trying to load a PIE executable produced by golang show the following (for pthread_create)
12: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND pthread_create
12655: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND pthread_create

It's the same for Linux or Solaris, so I suppose we're being too picky.

Change-Id: Ibe817c231365aba8b2eb88eb3f556d2bd1db384a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5392
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

runtime_loader: Support resolving weak symbols as NULL.

In the case where a weakly declared symbol has no definition,
it should just resolved to be NULL instead of failing to load at all.

GCC 11 builds of libroot.so wind up having one weak symbol
declaration that is unresolved at runtime, to __cxa_pure_virtual,
which seems to be provided by some object in libsupc++.a that ld
does not pull in automatically (and has to be forced at present.)

This change also amends symbol patcher behavior: it is now possible
for the symbol patcher to indicate symbols should be hidden by
changing the passed-in type to 0, instead. (Otherwise, weak symbols
would always get a value of NULL instead of being able to be hidden.)

Fixes #8288.

Previously-reviewed-on: https://review.haiku-os.org/c/haiku/+/4768
Change-Id: I6485c4e515cb53c6b81db971efbc10008fa6bd9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4932
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Revert "runtime_loader: Support resolving weak symbols as NULL."

This reverts commit 74843df324e016ba448174c9f9e5b142ef728a67.

Reason for revert: Change was not ready, see comments on #8288.

Change-Id: I82dc23ca5a86fa2906fb6eb19f9f872603618fad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4897
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

runtime_loader: Support resolving weak symbols as NULL.

In the case where a weakly declared symbol has no definition,
it should just resolved to be NULL instead of failing to load at all.

GCC 11 builds of libroot.so wind up having one weak symbol
declaration that is unresolved at runtime, to __cxa_pure_virtual,
which seems to be provided by some object in libsupc++.a that ld
does not pull in. We could probably force it to be, but implementing
proper weak symbol resolution seems to be the more sensible path.

Change-Id: Ifd512b73dc67581e6173b5c78ce73ac68971707a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4768
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

runtime_loader: treat weak symbols as strong symbols definitions.

http://www.sourceware.org/ml/libc-hacker/2000-06/msg00029.html
Change-Id: I15bf1f48dda32942e2a93610d62dabe0cabdc9a1
Reviewed-on: https://review.haiku-os.org/c/1191
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

style fix.

runtime_loader: allow the ABI version symbol to be local.

Some libraries buildsystems (eg. zlib) somehow prevent the symbol from
being exported. We should fix that, but binaries with missing symbols
are already out there, so we need to handle them in any case.

runtime_loader: keep symbol DSO in SymbolLookupCache

While resolving TLS related relocations it is necessary to know the DSO
that defines the symbol. Without proper support in caching that information
is available only when the symbol is resolved first time. That works well
for TLS since TLS_DTPMOD is guaranteed to be before TLS_DTPOFF relocation.
This patch makes the newly introduced parts of the interface work in a
general case.

runtime_loader: support linking TLS symbols from any DSO

Previously TLS_DTPMOD relocation blindly returned ID of the current DSO.
This patch does proper symbol lookup if there is a symbol assigned to the
relocation and uses ID of the DSO in which the symbol is defined.

runtime_loader: add support for ELF based TLS

This patch introduces support of ELF based TLS handling with lazy allocation
and initalization of TLS block for each DSO and thread. The implementation
generally follows the official ABI except that generation counter in dtv
is in fact a pointer to Generation object that contains both generation
counter and size of the dtv. That simplified the implementation a bit, but
could be changed later. The ABI requirements regariding in memory position
of TLS block is not honoured what results in static TLS model being
unsupported. However, that should not be a problem as long as
"executables" in Haiku are in fact shared objects and optimizations which
require specific TLS block in memory layout are not possible anyway.

Changed runtime_loader to use elf_* typedefs over Elf32_*.

This means that it will be using ELF64 types on x86_64 rather than
ELF32. The next step for supporting x86_64 is to implement relocations.

find_undefined_symbol_add_on(): Resolve non-weak symbols defined in the add-on
to themselves. This works around the problem that those symbols could be
resolved to symbols in the application, which is usually undesired. Weak
symbols have the same problem, but the the runtime loader cannot decide which
should be resolved locally and which mustn't.

The root issue is that BeOS style add-ons simply cannot be supported by a
standard-complying ELF loader.

Affects gcc 4 only, since with gcc 2 we link everything symbolically. The best
solution for the time being would be to build gcc 4 add-ons with default
hidden visibility, exporting only the symbols that should be visible.

Related ticket: #7114


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40248 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_undefined_symbol_beos(): Forgot to return the image in the code
introduced in r40211.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40228 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added SymbolLookupInfo::requestingSymbol which is passed in by
resolve_symbol().
* find_undefined_symbol_beos(): Does now check whether
SymbolLookupInfo::requestingSymbol is defined, and, if so, returns it
directly. This saves the time for the hash table lookup and also works
around broken files like SoundPlay. Fixes the runtime loader part of #7094.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40211 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_undefined_symbol_beos(): Look up the symbol in the requesting image
first. Fixes binary compatibility issue introduced with symbol preemption
support in the runtime loader. For unknown reasons liblayout.so, though
linked symbolically, contains a non-weak (!), preemptable BFont type info,
which was no longer resolved correctly with the new method.
Fixes #6892.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39617 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Merged weak-symbols branch.
* Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp
* Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96

* find_symbol_breadth_first() didn't ever set _foundInImage, although
it's signature indicates that it should - the callers just never use
the value currently, so it caused no harm
* squashed a TODO in the runtime_loader about the resolving strategy
for undefined symbols in add-ons: I've implemented the breadth-first
strategy (leaving out the add-on itself), as that one made most sense to
me.
This avoids loader problems with older optional packages of Pe on gcc4, as some
add-ons (e.g. "Expand Tabs") could not be loaded due to them containing undefined
symbols that are found in second level dependencies (libstdc++.so in this case).

Ingo: please review.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Normalized the FATAL messages. The image path is always printed, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30878 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed remapping of the *stat() symbols for BeOS executables. We'll use
symbol versioning instead.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30829 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved most code of the heavy elf.cpp into several smaller source files.
* Some style cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30808 a95241bf-73f2-0310-859d-f6bbb57e9c96

runtime_loader: keep symbol DSO in SymbolLookupCache

While resolving TLS related relocations it is necessary to know the DSO
that defines the symbol. Without proper support in caching that information
is available only when the symbol is resolved first time. That works well
for TLS since TLS_DTPMOD is guaranteed to be before TLS_DTPOFF relocation.
This patch makes the newly introduced parts of the interface work in a
general case.

runtime_loader: support linking TLS symbols from any DSO

Previously TLS_DTPMOD relocation blindly returned ID of the current DSO.
This patch does proper symbol lookup if there is a symbol assigned to the
relocation and uses ID of the DSO in which the symbol is defined.

runtime_loader: add support for ELF based TLS

This patch introduces support of ELF based TLS handling with lazy allocation
and initalization of TLS block for each DSO and thread. The implementation
generally follows the official ABI except that generation counter in dtv
is in fact a pointer to Generation object that contains both generation
counter and size of the dtv. That simplified the implementation a bit, but
could be changed later. The ABI requirements regariding in memory position
of TLS block is not honoured what results in static TLS model being
unsupported. However, that should not be a problem as long as
"executables" in Haiku are in fact shared objects and optimizations which
require specific TLS block in memory layout are not possible anyway.

Changed runtime_loader to use elf_* typedefs over Elf32_*.

This means that it will be using ELF64 types on x86_64 rather than
ELF32. The next step for supporting x86_64 is to implement relocations.

find_undefined_symbol_add_on(): Resolve non-weak symbols defined in the add-on
to themselves. This works around the problem that those symbols could be
resolved to symbols in the application, which is usually undesired. Weak
symbols have the same problem, but the the runtime loader cannot decide which
should be resolved locally and which mustn't.

The root issue is that BeOS style add-ons simply cannot be supported by a
standard-complying ELF loader.

Affects gcc 4 only, since with gcc 2 we link everything symbolically. The best
solution for the time being would be to build gcc 4 add-ons with default
hidden visibility, exporting only the symbols that should be visible.

Related ticket: #7114


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40248 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_undefined_symbol_beos(): Forgot to return the image in the code
introduced in r40211.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40228 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added SymbolLookupInfo::requestingSymbol which is passed in by
resolve_symbol().
* find_undefined_symbol_beos(): Does now check whether
SymbolLookupInfo::requestingSymbol is defined, and, if so, returns it
directly. This saves the time for the hash table lookup and also works
around broken files like SoundPlay. Fixes the runtime loader part of #7094.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40211 a95241bf-73f2-0310-859d-f6bbb57e9c96

find_undefined_symbol_beos(): Look up the symbol in the requesting image
first. Fixes binary compatibility issue introduced with symbol preemption
support in the runtime loader. For unknown reasons liblayout.so, though
linked symbolically, contains a non-weak (!), preemptable BFont type info,
which was no longer resolved correctly with the new method.
Fixes #6892.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39617 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Merged weak-symbols branch.
* Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp
* Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96

* find_symbol_breadth_first() didn't ever set _foundInImage, although
it's signature indicates that it should - the callers just never use
the value currently, so it caused no harm
* squashed a TODO in the runtime_loader about the resolving strategy
for undefined symbols in add-ons: I've implemented the breadth-first
strategy (leaving out the add-on itself), as that one made most sense to
me.
This avoids loader problems with older optional packages of Pe on gcc4, as some
add-ons (e.g. "Expand Tabs") could not be loaded due to them containing undefined
symbols that are found in second level dependencies (libstdc++.so in this case).

Ingo: please review.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Normalized the FATAL messages. The image path is always printed, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30878 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed remapping of the *stat() symbols for BeOS executables. We'll use
symbol versioning instead.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30829 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved most code of the heavy elf.cpp into several smaller source files.
* Some style cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30808 a95241bf-73f2-0310-859d-f6bbb57e9c96