On sexta-feira, 25 de outubro de 2013 11:57:25, Jan Engelhardt wrote: > >The drawbacks of this solution are: > > - no link-time dependency for packaging tools to detect and create the > > > > package dependency without intervention > > Given most .run-type software bypasses package tools already, > there is not much more to lose.
Good point. I was thinking of the case of distributions that potentially
forgot to enable direct linking and instead fell back to the dynamic loading
code. We probably have to make our code smart enough so that this won't
happen.
> > - sub-optimal resolution and calling (hand-written code worse than linker-
> >
> > generated PLT)
>
> How worse is it, actually?
>
> 5 void *h = dlopen("libc.so.6", RTLD_LAZY);
> (gdb) n
> 6 int (*scmp)(const char *, const char *) = dlsym(h,
> "strcmp"); (gdb)
> 7 return scmp(argv[0], "x.c") == 0;
> (gdb) p scmp
> $1 = (int (*)(const char *, const char *)) 0x7ffff7953c40 <__strcmp_ssse3>
>
>
> So even though I used the, as you call it, "suboptimal" dlopen mechanism,
> I do get the SSSE3-optimized variant. Can't be _that_ bad.
That's not what I meant. Yes, both variants will call the same function.
I meant that the code you wrote above (dlopen-dlsym-call, plus handling dlopen
failing) is worse than the equivalent solution generated by the linker and
dynamic linker for the case when we are allowed to link directly.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
