src-test2/usr.bin/ldd, branch release/8.4.0 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F8.4.0 2011-06-06T21:07:44Z MFC 199871 [1]: 2011-06-06T21:07:44Z Glen Barber gjb@FreeBSD.org 2011-06-06T21:07:44Z urn:sha1:1c31f97cbf11882ce7d1a57453662992aa30d6cb - correctly render the provided example PR: 140962 Obtained from: danger [1] MFC: r215705: hdr.elf.e_ident[EI_OSABI] is not a bitmask 2010-11-24T22:44:10Z David E. O'Brien obrien@FreeBSD.org 2010-11-24T22:44:10Z urn:sha1:60a0d00a467429f5b70e153e4ff7be69ca9c6744 A few style and whitespace fixes. 2008-08-02T12:04:59Z John Baldwin jhb@FreeBSD.org 2008-08-02T12:04:59Z urn:sha1:52122f3139311d4fac507a7a1de5f64ff4844283 Submitted by: bde Tweak the support for using ldd on 32-bit objects a bit further. 2008-08-01T21:52:41Z John Baldwin jhb@FreeBSD.org 2008-08-01T21:52:41Z urn:sha1:e68ed7939063ce59c1c15038a0f245e7b642c9f7 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) Fix text in the comment why we check for ELF32_R_TYPE 2008-07-28T12:49:16Z Edwin Groothuis edwin@FreeBSD.org 2008-07-28T12:49:16Z urn:sha1:bff7135050eb7efba7d740eb982d8f664ee9ede6 Approved by: bde@ MFC after: 2 days2 days After the commit of SVN rev 180236, wilko@ noticed that the approach 2008-07-21T02:13:14Z Edwin Groothuis edwin@FreeBSD.org 2008-07-21T02:13:14Z urn:sha1:8bd833fff8e7658f77839cd1a3a8ecf48700e3f7 doesn't work on the Alpha platform: machine/elf.h doesn't include sys/elf32.h there. PR: related to bin/124906 Approved by: bde@ MFC after: 1 week On 64 bit architectures, you can run 32 bit executables and the rtld can trace them, but ldd(1) doesn't know yet how to detect them: 2008-07-03T22:37:51Z Edwin Groothuis edwin@FreeBSD.org 2008-07-03T22:37:51Z urn:sha1:fffd993df22e065682ca4178e172407a789ddca9 [/] 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 Extract the determination of the kind of (dynamic) executable from 2008-07-03T22:30:18Z Edwin Groothuis edwin@FreeBSD.org 2008-07-03T22:30:18Z urn:sha1:d3c1e14b41ef931cf5c1d3e8e26e22daa9854589 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 stylify ldd.c, no functional changes. 2008-07-03T22:26:43Z Edwin Groothuis edwin@FreeBSD.org 2008-07-03T22:26:43Z urn:sha1:a0d476a986fe9c5936043c63ae97e922ad0c2183 Approved by: bde (mentor) MFC after: 1 week Typo 2008-05-15T10:51:30Z Bruce M Simpson bms@FreeBSD.org 2008-05-15T10:51:30Z urn:sha1:7fa21c09b6c1db79e12dc7d6f15c1edd8fc9cbad