cling

gamzinav/cling

Fork 0

Commit Graph

Author	SHA1	Message	Date
Vassil Vassilev	4fa39ba82f	Do not resolve symbols from executables compiled with -fPIE. Executables that are compiled with fPIE means they are compiled in a position independent manner and are almost indistinguishable from the shared objects. A reasonably reliable way to find if this was a `pie executable` is to check the `DF_1_PIE` in the dynamic section of ELF. The pseudo-code is: ``` if DT_FLAGS_1 dynamic section entry is present if DF_1_PIE is set in DT_FLAGS_1: print pie executable else print shared object ``` See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357 Fixes root-project/root#7366 Patch by Alexander Penev (@alexander-penev)	2022-01-07 16:29:03 +01:00
Vassil Vassilev	d36bfe15e4	Ask for the real path in any case.	2021-08-07 09:29:07 +02:00
Vassil Vassilev	55a4e89b3b	Fix ROOT-10484 by implementing dyld support for RPATH. Some libraries are layered can depend on other libraries on a private paths. That is, libA can depend on libB which is neither on the LD_LIBRARY_PATH nor on a known system path. The posix linker injects "variables" such as @rpath which is expanded at link time to resolve the libraries on a relative path. Prior to this patch, cling's Dyld-based symbol resolution could not trace down such cases causing failures in symbol resolution when a symbol is only defined in libB (a private library). This patch implements the basic posix linker substitutions allowing cling's Dyld-based symbol resolution implementation to follow more closely the linker rules. Kudos Alexander Penev (@alexander-penev).	2021-08-07 09:29:07 +02:00

Author

SHA1

Message

Date

Vassil Vassilev

4fa39ba82f

Do not resolve symbols from executables compiled with -fPIE.

Executables that are compiled with fPIE means they are compiled in a position
independent manner and are almost indistinguishable from the shared objects. A
reasonably reliable way to find if this was a `pie executable` is to check the
`DF_1_PIE` in the dynamic section of ELF.

The pseudo-code is:
```
if DT_FLAGS_1 dynamic section entry is present
  if DF_1_PIE is set in DT_FLAGS_1:
    print pie executable
  else
    print shared object
```

See https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/34522357#34522357

Fixes root-project/root#7366

Patch by Alexander Penev (@alexander-penev)

2022-01-07 16:29:03 +01:00

Vassil Vassilev

d36bfe15e4

Ask for the real path in any case.

2021-08-07 09:29:07 +02:00

Vassil Vassilev

55a4e89b3b

Fix ROOT-10484 by implementing dyld support for RPATH.

Some libraries are layered can depend on other libraries on a private paths.
That is, libA can depend on libB which is neither on the LD_LIBRARY_PATH nor
on a known system path. The posix linker injects "variables" such as @rpath
which is expanded at link time to resolve the libraries on a relative path.

Prior to this patch, cling's Dyld-based symbol resolution could not trace down
such cases causing failures in symbol resolution when a symbol is only defined
in libB (a private library).

This patch implements the basic posix linker substitutions allowing cling's
Dyld-based symbol resolution implementation to follow more closely the linker
rules.

Kudos Alexander Penev (@alexander-penev).

2021-08-07 09:29:07 +02:00

3 Commits