The -a option also requires passing specific environment variables to
instance of rtld doing tracing.
PR: 259069
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Problem is that rtld cannot reliably access updated environment.
This was made more obvious by bfd4c875a1. The application
environment can be in arbitrary state and place, system components
can observe it only during execve(2), or in case of rtld, right after
execve, when environment is still at know location and format.
Instead spawn ld-elf.so.1 in direct exec mode which can correctly read
all inherited updates to the environment.
PR: 259069
Reviewed by: arichardson, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32464
It seems -v only worked for a.out. Remove it, not even keeping the current
nop for compat. Also remove more mentions of a.out format from the man
page.
Reviewed by: dim, emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31708
- Use libelf to parse ELF data structures and remove code duplication
for ELF32.
- Don't require the OSABI field to be set to the FreeBSD OSABI for
shared libraries. Both AArch64 and RISC-V leave it set to "none"
and instead depend on the ABI tag note. For ldd, this means falling
back to walking the notes in PT_NOTE segments to find the ABI tag
note to determine if an ELF shared library without OSABI set in the
header file is a FreeBSD shared library.
Reviewed by: kib
MFC after: 5 days
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D28342
ldd had #defines for AOUT, ELF, and ELF32. The removal of AOUT left a
possibly confusing gap. These are not used anywhere but this file so
renumber to avoid the gap.
Reported by: allanjude
Userland aout support has not been required since FreeBSD 2.x.
If someone needs to use FreeBSD 2 shared libraries they will be best
served by using a FreeBSD 2 ldd, perhaps as part of a jail with a full
FreeBSD 2.x install.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27478
ldd proclaims ET_DYN objects as shared libraries and tries to
dlopen(RTLD_TRACE) them to get dependencies. Since PIE binaries are
ET_DYN | DF_1_PIE, refusal to dlopen such binaries breaks ldd.
Fix it by reading and parsing dynamic segment looking for DF_FLAG_1
and taking DF_1_PIE into account when deciding between binary and
library.
Reported by: Dewayne Geraghty <dewayne@heuristicsystems.com.au>
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25257
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler.
This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define
per each extension, so together with __riscv we will have some subset
of these as well (depending on -march string passed to compiler):
__riscv_compressed
__riscv_atomic
__riscv_mul
__riscv_div
__riscv_muldiv
__riscv_fdiv
__riscv_fsqrt
__riscv_float_abi_soft
__riscv_float_abi_single
__riscv_float_abi_double
__riscv_cmodel_medlow
__riscv_cmodel_medany
__riscv_cmodel_pic
__riscv_xlen
Reviewed by: ngie
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11901
Specifically, build a 32-bit /usr/bin/ldd32 on amd64 which handles 32-bit
objects. Since it is a 32-bit binary, it can fork a child process which
can dlopen() a 32-bit shared library. The current 32-bit support in ldd
can't do this because it does the dlopen() from a 64-bit process. In order
to preserve an intuitive interface for users, the ldd binary automatically
execs /usr/bin/ldd32 for 32-bit objects. The end result is that ldd on
amd64 now transparently handles 32-bit shared libraries in addition to
32-bit binaries.
Submitted by: ps (indirectly)
[/] root@ed-exigent>ldd `which httpd`
ldd: /usr/local/sbin/httpd: can't read program header
ldd: /usr/local/sbin/httpd: not a dynamic executable
But...
[/] root@ed-exigent>LD_32_TRACE_LOADED_OBJECTS==1 `which httpd`
libm.so.4 => /lib32//libm.so.4 (0x280c8000)
libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280de000)
libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f2000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000)
libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x281fd000)
libcrypt.so.3 => /lib32//libcrypt.so.3 (0x2821d000)
libpthread.so.2 => not found (0x0)
libc.so.6 => /lib32//libc.so.6 (0x28235000)
libpthread.so.2 => /usr/lib32/libpthread.so.2 (0x2830d000)
Added support in ldd(1) for the LD_32_xxx environment variables if
the architecture of the machine is >32 bits. If we ever go to 128
bit architectures this excercise will have to be repeated but thanks
to earlier commits today it will be relative simple.
PR: bin/124906
Submitted by: edwin
Approved by: bde (mentor)
MFC after: 1 week
the main-loop into a seperate function.
Instead of using hardcoded environment variables, define them in a
lookup table.
For the rest, no functionality changes.
Approved by: bde (mentor)
MFC after: 1 week
even if there was no error occured (when trying to dlopen(3) object that
already linked into executable which does dlopen(3) call). This is more
proper fix for `ldd /usr/lib/libc.so' problem, because the new behaviour
conforms to documentation.
Remove workaround from ldd.c (rev.1.32).
PR: 35099
Submitted by: Nathan Hawkins <utsl@quic.net>
MFC after: 1 week
returns, exit gracefully with 0.
This fixes the behavior you see when you specify libc.so. It occurs
because ldd(1) itself is linked with libc.so.
$ ldd /usr/lib/libc.so
/usr/lib/libc.so:
ldd: /usr/lib/libc.so: (null)
/usr/lib/libc.so: exit status 1
Reviewed by: silence of audit@
longer includes machine/elf.h.
* consumers of elf.h now use the minimalist elf header possible.
This change is motivated by Binutils 2.11.0 and too much clashing over
our base elf headers and the Binutils elf headers.
Bring the style of sods.c into better conformance. Add code to
print the contents of each datum being relocated. Correct the logic
that distinguishes between programs, shared libraries, and object
files. Make the entire program "-Wall" clean.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
