runtime_loader: dlopen() should respect RPATH of the loading module

Change-Id: Ic58edb53114dfff30cc7188957cd32508fa8bd48
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3798
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

Remove arch_get_caller

Use the gcc builtin instead, which generates more efficient code (it
saves a function call) and means less platform specific code to write
for us.

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

libroot.so: make first parameter of dladdr() const.

This follows up on a mail from 2011:
https://www.freelists.org/post/haiku-development/Changing-dladdr-to-take-const-void-for-first-parameter

runtime_loader: Add imageName and exactMatch to symbol lookup.

Extend the get_nearest_symbol_at_address() private runtime_loader
export to include imageName and exactMatch arguments.

The imageName holds the SONAME of the image, if available, so cannot
neccessarily be extracted from the image path.

Whether or not there was an exact match, i.e. the symbol with its size
contains the address, is now returned in exactMatch.

Fix dladdr behaviour

* If dladdr can't find an exact match, it returns the nearest symbol
less than the given address.
* If no suitable symbol can be found, but the address is within a
loaded library, dladdr returns the library name and base address.

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

* Implemented dladdr() in the runtime loader. This is like a gazillion times
faster than before.
* This also solves a TODO in dladdr(), although I did not use
get_library_symbol() as I didn't quite see how that could fit as the comment
suggested; there is now a new function get_symbol_at_address() for this.


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

* dladdr() apparently should work on any symbol, not just functions. This
closes bug #6491.


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

dlclose() also set the static error variable.


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

* Reworked undefined symbol resolution in the runtime loader. Got rid of
the per-root-image breadth-first sorted image array. Instead we have a
per-image hook function to resolve the symbols. The default function
uses the sLoadedImages list directly, which is breadth-first sorted
anyway. There's also a BeOS function for old-style symbol resolution
and one for add-ons, which lacks a proper implementation yet (just
uses old-style ATM).
* Made the dl*() functions POSIX compliant:
- dlopen() does no longer use load_add_on(), but loads the object as a
library. It also properly supports a NULL name, now -- the previous
"_APP_" work-around did only work, if this soname was set on the
program (unlikely for programs using this API).
- Implemented RTLD_{GLOBAL,LOCAL}.
- dlsym() looks up symbols properly now, i.e. not just in the given
image, but breadth-first for an actual image or in load order for
the global scope. It also supports the not-quite POSIX RTLD_DEFAULT
and RTLD_NEXT extensions. Our RTLD_NEXT finds more symbols than in
Linux (also in later dlopen()ed libraries), but that should be fine.


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

Moved the rld_export structure from <user_runtime.h> to
<runtime_loader.h>, since it isn't a kernel <-> userland interface.


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

* Applied patch by Romain Picard: added support for the GNU extension dladdr(),
thanks!
* This closes ticket #2818.


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

Fix warnings about missing protos.


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

Added TODO.


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

first steps towards enabling support for wide chars in our libroot: reverted mbrtowc.c to glibc 2.2.5, added necessary iconv support to let it compile, added dl*** wrappers for needed glibc functions. Not sure it's the correct path, but let's try, at least.

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

Made our glue code compatible to BeOS again. IOW executables compiled for Haiku will
now run under BeOS as well (as long as they don't use any functions that are not
available under R5).
The solution is a bit messy, but we have to live with it :-)
The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point
to its exported structure instead of passing it to the init functions as an
argument.
(Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile)


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

Renamed src/kernel to src/system.


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

runtime_loader: Add imageName and exactMatch to symbol lookup.

Extend the get_nearest_symbol_at_address() private runtime_loader
export to include imageName and exactMatch arguments.

The imageName holds the SONAME of the image, if available, so cannot
neccessarily be extracted from the image path.

Whether or not there was an exact match, i.e. the symbol with its size
contains the address, is now returned in exactMatch.

Fix dladdr behaviour

* If dladdr can't find an exact match, it returns the nearest symbol
less than the given address.
* If no suitable symbol can be found, but the address is within a
loaded library, dladdr returns the library name and base address.

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

* Implemented dladdr() in the runtime loader. This is like a gazillion times
faster than before.
* This also solves a TODO in dladdr(), although I did not use
get_library_symbol() as I didn't quite see how that could fit as the comment
suggested; there is now a new function get_symbol_at_address() for this.


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

* dladdr() apparently should work on any symbol, not just functions. This
closes bug #6491.


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

dlclose() also set the static error variable.


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

* Reworked undefined symbol resolution in the runtime loader. Got rid of
the per-root-image breadth-first sorted image array. Instead we have a
per-image hook function to resolve the symbols. The default function
uses the sLoadedImages list directly, which is breadth-first sorted
anyway. There's also a BeOS function for old-style symbol resolution
and one for add-ons, which lacks a proper implementation yet (just
uses old-style ATM).
* Made the dl*() functions POSIX compliant:
- dlopen() does no longer use load_add_on(), but loads the object as a
library. It also properly supports a NULL name, now -- the previous
"_APP_" work-around did only work, if this soname was set on the
program (unlikely for programs using this API).
- Implemented RTLD_{GLOBAL,LOCAL}.
- dlsym() looks up symbols properly now, i.e. not just in the given
image, but breadth-first for an actual image or in load order for
the global scope. It also supports the not-quite POSIX RTLD_DEFAULT
and RTLD_NEXT extensions. Our RTLD_NEXT finds more symbols than in
Linux (also in later dlopen()ed libraries), but that should be fine.


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

Moved the rld_export structure from <user_runtime.h> to
<runtime_loader.h>, since it isn't a kernel <-> userland interface.


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

* Applied patch by Romain Picard: added support for the GNU extension dladdr(),
thanks!
* This closes ticket #2818.


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

Fix warnings about missing protos.


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

Added TODO.


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

first steps towards enabling support for wide chars in our libroot: reverted mbrtowc.c to glibc 2.2.5, added necessary iconv support to let it compile, added dl*** wrappers for needed glibc functions. Not sure it's the correct path, but let's try, at least.

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

Made our glue code compatible to BeOS again. IOW executables compiled for Haiku will
now run under BeOS as well (as long as they don't use any functions that are not
available under R5).
The solution is a bit messy, but we have to live with it :-)
The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point
to its exported structure instead of passing it to the init functions as an
argument.
(Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile)


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

Renamed src/kernel to src/system.


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