Re: ldd runs linux programs

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)