On Fri, Sep 2, 2016 at 1:35 AM, Nadav Har'El <[email protected]> wrote:
> > On Fri, Sep 2, 2016 at 12:58 AM, Paweł Dziepak <[email protected]> > wrote: > >> On 1 September 2016 at 12:05, Nadav Har'El <[email protected]> wrote: >> >> BUT, from the code we've inspected, it seems that golang-compiled code >>> doesn't use this technique. Instead, it seems it uses arch_prctl's >>> ARCH_SET_FS to completely take over the fs_base of Go threads. This would >>> cause big problems for us when these Go threads want to call other non-Go >>> functions (in OSv, the system calls are ordinary functions too). >>> >> >> Is this really a problem? AFAIK Go programs don't call OSv functions >> directly and use syscall instruction for everything. This means that we >> have only two places where change between executing Go program and OSv can >> occur: syscall and interrupt. We could add logic in those places that would >> set %fs appropriately to the application needs. >> >> In other words, once application uses ARCH_SET_FS OSv would maintain two >> %fs values. One to be set when OSv itself is executing (and the libraries >> it uses) and the other when the application runs. The switch between these >> values happens at interrupt and syscall exit and entry. Obviously, we won't >> be able to support applications that use ARCH_SET_FS *and* link against >> symbols provided by OSv but it happens to be sufficient solution for Go >> programs. >> > > Maybe "big" problem was an overstatement, but it's a problem, because > beyond the system calls, golang compiled programs also appear to use some > glibc functions - at least when compiled as shared libraries. > > But it now appears that prctl either sets fs_base to the value the C > library already wants (according to David) or not used at all in shared > objects (according to Michael), so there should be nothing to worry about > it, and can postpone the fs_base-switching code in OSv (perhaps we'll need > to do it one day, but not for running golang shared objects). > When Go binary uses glibc pthread functions, it will not set fs_base. The code might be included, but it won't be called in that case. The set fs_base code is only used for fully static Go binaries. I hope this clears thing up. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
