Re: Using stock PIE executables from standard distributions?
On Mon, Jan 29, 2018 at 9:02 AM, Nadav Har'El wrote: > > On Mon, Jan 29, 2018 at 12:37 AM, Rick Payne wrote: > >> >> >> > On 28 Jan 2018, at 22:23, Nadav Har'El wrote: >> > >> > However, sadly, we still do have bugs with PIE support that need to be >> fixed before running PIEs on OSv becomes a hassle-free experience: >> > >> > A bug which relatively-recently became relevant (as gcc changed) is >> https://github.com/cloudius-systems/osv/issues/689, which prevents PIEs >> which use getopt() with "optarg" from working. >> > A harder bug is https://github.com/cloudius-systems/osv/issues/352 >> which I think is still partially relevant - I think we still have problems >> with thread-local variables in PIEs (but not in shared libraries). >> > >> > Please check the PIE which interests you, and see if one of these bugs >> affects you, or if there are any other bugs. >> > Both the aforementioned bug reports contain also ideas on how to fix >> them, if you're looking for >> >> Aha, and maybe my ERTS issue was another bug? >> > > Did you compile it as -pie, -fpie? Or -shared -fPIC? > > Is your Erlang problem something reproducable using the apps/erlang > somehow? > > I tried with gcc 7.2.1, > scripts/build -j5 image=erlang; scripts/run.py -V > but get a different error: > > /usr/lib64/erlang/erts-7.0/bin/beam.smp: failed looking up symbol tgetent > Oh, this is a yet another case of compiling with one version of the library, then putting a different version in the image. I opened https://github.com/cloudius-systems/osv/issues/943 > > [backtrace] > 0x0033a7cf > 0x0033d384 > 0x0033d555 > > Something happened to the termcap library? Weird. > > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using stock PIE executables from standard distributions?
On Mon, Jan 29, 2018 at 12:37 AM, Rick Payne wrote: > > > > On 28 Jan 2018, at 22:23, Nadav Har'El wrote: > > > > However, sadly, we still do have bugs with PIE support that need to be > fixed before running PIEs on OSv becomes a hassle-free experience: > > > > A bug which relatively-recently became relevant (as gcc changed) is > https://github.com/cloudius-systems/osv/issues/689, which prevents PIEs > which use getopt() with "optarg" from working. > > A harder bug is https://github.com/cloudius-systems/osv/issues/352 > which I think is still partially relevant - I think we still have problems > with thread-local variables in PIEs (but not in shared libraries). > > > > Please check the PIE which interests you, and see if one of these bugs > affects you, or if there are any other bugs. > > Both the aforementioned bug reports contain also ideas on how to fix > them, if you're looking for > > Aha, and maybe my ERTS issue was another bug? > Did you compile it as -pie, -fpie? Or -shared -fPIC? Is your Erlang problem something reproducable using the apps/erlang somehow? I tried with gcc 7.2.1, scripts/build -j5 image=erlang; scripts/run.py -V but get a different error: /usr/lib64/erlang/erts-7.0/bin/beam.smp: failed looking up symbol tgetent [backtrace] 0x0033a7cf 0x0033d384 0x0033d555 Something happened to the termcap library? Weird. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using stock PIE executables from standard distributions?
> On 28 Jan 2018, at 22:23, Nadav Har'El wrote: > > However, sadly, we still do have bugs with PIE support that need to be fixed > before running PIEs on OSv becomes a hassle-free experience: > > A bug which relatively-recently became relevant (as gcc changed) is > https://github.com/cloudius-systems/osv/issues/689, which prevents PIEs which > use getopt() with "optarg" from working. > A harder bug is https://github.com/cloudius-systems/osv/issues/352 which I > think is still partially relevant - I think we still have problems with > thread-local variables in PIEs (but not in shared libraries). > > Please check the PIE which interests you, and see if one of these bugs > affects you, or if there are any other bugs. > Both the aforementioned bug reports contain also ideas on how to fix them, if > you're looking for Aha, and maybe my ERTS issue was another bug? Rick -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using stock PIE executables from standard distributions?
On Sat, Jan 27, 2018 at 5:09 PM, Dan Kaminsky wrote: > Given that OSv implements its own ELF loader, I'm wondering how much it > could potentially take advantage of platforms' recent change to PIE > compilation. (GCC7 is PIE by default, a thing that's been some headache for > kernel compilation.) PIE binaries are almost entirely identical to shared > libraries, relocatable top to bottom. > I wasn't aware that gcc7 changed to compilation to PIE by default. OSv does already support running PIE! So if you have a pre-compiled PIE, you can try running it, and not recompile it to a shared library. However, sadly, we still do have bugs with PIE support that need to be fixed before running PIEs on OSv becomes a hassle-free experience: A bug which relatively-recently became relevant (as gcc changed) is https://github.com/cloudius-systems/osv/issues/689, which prevents PIEs which use getopt() with "optarg" from working. A harder bug is https://github.com/cloudius-systems/osv/issues/352 which I think is still partially relevant - I think we still have problems with thread-local variables in PIEs (but not in shared libraries). Please check the PIE which interests you, and see if one of these bugs affects you, or if there are any other bugs. Both the aforementioned bug reports contain also ideas on how to fix them, if you're looking for > > Build systems are actually hilariously fragile so "just" adding a > compilation flag is a bigger problem than you'd think. It'd be interesting > to just be able to mine a host operating system, or even package manager, > for dependencies even if you didn't just pull them at runtime directly. > I agree, and some of this is already possible because shared libraries can be used on OSv without any recompilation, so we often run "ldd" on a program and just copy all the shared-library dependencies to the image (a lot of the examples in apps/ do that). Nadav. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Using stock PIE executables from standard distributions?
Given that OSv implements its own ELF loader, I'm wondering how much it could potentially take advantage of platforms' recent change to PIE compilation. (GCC7 is PIE by default, a thing that's been some headache for kernel compilation.) PIE binaries are almost entirely identical to shared libraries, relocatable top to bottom. Build systems are actually hilariously fragile so "just" adding a compilation flag is a bigger problem than you'd think. It'd be interesting to just be able to mine a host operating system, or even package manager, for dependencies even if you didn't just pull them at runtime directly. Relatedly, I've gotten some decent progress using whole-language-llvm or gclang, extracting the final bitcode, and then compiling that as a shared library. But, that's for environments where there's not an actively maintained ELF loader. You actually have one. Of course there may be other aspects I'm missing, thus me asking instead of just diving in directly. --Dan -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
