On Wed, Jul 31, 2013 at 10:12:31PM -0400, Mark Johnston wrote: > On Mon, Jul 29, 2013 at 10:54:49PM +0200, Mateusz Guzik wrote: > > On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: > > > > 127276 suggests running the binary as is (which I don't like) and > > > > achieves this with a hacky way. So if we really want to do this, the > > > > patch should be reworked to detect Linux binaries properly. > > > > > > > > In general we should gain linux_ldd (like linux_kdump) and our ldd > > > > should work only on FreeBSD binaries. The last part is achieved with my > > > > patch. > > > > > > > > markj, are you working on this? > > > > > > Not really; my original fix for this problem was essentially the same as > > > yours. That is, just change ldd(1) to bail if the OS ABI byte isn't > > > equal to ELFOSABI_FREEBSD. That's the change I have committed in my > > > local tree right now. > > > > > > Then I thought I'd try to get ldd to work properly with Linux binaries > > > as well, but wasn't sure what the right approach should be. As the above > > > PR suggests, the easy thing to do is to just pass > > > LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit > > > ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, > > > but I didn't really see another approach. > > > > > > That said, I think your patch should be committed since it's clearly an > > > improvement over the current behaviour. I'm willing to test and commit > > > it, and clean up the open PRs. If you could expand on the right way to > > > handle Linux binaries, I'd be willing to implement and commit that too. > > > I don't quite understand your reference to linux_kdump though - I have > > > no such program on my laptop running CURRENT, and ktrace+kdump seem to > > > work fine with the Linux binaries under /compat/linux. > > > > > > > Well, there was linux_kdump in ports but it apparently got obsolete as > > necessary support for included in our regular kdump. > > > > So it may make sense to teach our ldd how to deal with Linux binaries > > for consistency, but its unclear for me if this is better than providing > > linux_ldd. Also there is the problem of (not) appending /compat/linux to > > printed paths (for Linux binaries the kernel performs file lookups against > > /compat/linux first). I'm not that interested in this problem though. :P > > What do you think of the patch below, which just sets both variables in > the compat case? It's somewhat less intrusive than the patch in the PR. > If that's no good then I'll just commit your original patch; I really > just want to fix the fact that the example pipeline in the ldd(1) man > page starts a GTK program (some Adobe Flash thingy to be specific) when > run in /usr/local/bin on my desktop machine. :) > > Thanks, > -Mark > > diff --git a/usr.bin/ldd/ldd.c b/usr.bin/ldd/ldd.c > index 00c8797..71e9c8d 100644 > --- a/usr.bin/ldd/ldd.c > +++ b/usr.bin/ldd/ldd.c > _at__at_ -51,6 +51,7 _at__at_ __FBSDID("$FreeBSD$"); > > #ifdef COMPAT_32BIT > #define LD_ "LD_32_" > +#define LD_COMPAT_ "LD_" > #else > #define LD_ "LD_" > #endif > _at__at_ -211,6 +212,13 _at__at_ main(int argc, char *argv[]) > > /* ld.so magic */ > setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); > +#ifdef COMPAT_32BIT > + /* > + * Set this for the benefit of runtime linkers that don't know > + * we're in compat mode. > + */ > + setenv(LD_COMPAT_ "TRACE_LOADED_OBJECTS", "yes", 1); > +#endif > if (fmt1 != NULL) > setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); > if (fmt2 != NULL) I do not understand this COMPAT_32BIT business in ldd(1). Its only application seems to preventing ldd 32bit binary from amd64 host to work on i386 ? IMO, both LD_TRACE and LD_32_TRACE should be passed unconditionally always. I do not see any harm of doing this.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC