Re: [RFC PATCH 00/11] Library OS support

[Isaku Yamahata <isaku.yamahata@gmail.com>]

Thanks for feedback.


On Thu, Sep 12, 2019 at 12:10:32AM +0000,
Joseph Myers <joseph@codesourcery.com> wrote:

> On Wed, 11 Sep 2019, Isaku Yamahata wrote:
> 
> > This patch is to add Library OS(LibOS in short) to glibc.
> > This is the first version of patch series to support LibOS.
> 
> I don't see anything here about host triplets being used.  I'd expect 
> x86_64-*-libos or similar (with consequent config.sub changes being 
> submitted to GNU config.git) but there's nothing to indicate that, and the 
> patch series is lacking documentation (NEWS, install.texi / regeneration 
> of INSTALL, other .texi files if applicable).  I'd also expect any new OS 
> to have appropriate additions to build-many-glibcs.py.  There are a great 
> many complications specific to existing GNU/Linux ABIs that ought to be 
> irrelevant in this case (compat support for old symbol versions, 
> enable-kernel support for different minimum kernel versions, etc.).

Let me clarify my scope. Multiple LibOSes (typically) emulate Linux system
call (with some change). LibOSes can run unmodified (dynamically linked)
Linux executables (with modified libc as shared library).
For example, its invocation looks like as follows.
native case: $ linux-executable
LibOS case:  $ libos_loader linux-executable

I'd like to have x86_64-*-linux support both native linux and multiple LibOSes
with single version of binary.

If we have multiple versions, for example,
  x86_64-*-linux
  x86_64-*-linux_libosX
  x86_64-*-linux_libosY
  ...
it doesn't scale. It will cause maintenance hell.


> Given the modification of generic files, you should verify that installed 
> stripped shared libraries for e.g. x86_64-linux-gnu are byte-for-byte 
> identical before and after the patch (or justify them not being so if they 
> aren't identical - I'd expect justifications of the form "this file has 
> line numbers in assertions that change").
> 
> There should not be any __x86_64__ conditionals in generic files; the 
> sysdeps structure should be used as appropriate instead.

Sure. Let me address it with next respin.

Thanks,
-- 
Isaku Yamahata <isaku.yamahata@gmail.com>