From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 791C44696C3 for ; Thu, 16 Apr 2020 15:13:53 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id u6so5941651ljl.6 for ; Thu, 16 Apr 2020 05:13:53 -0700 (PDT) Date: Thu, 16 Apr 2020 15:13:50 +0300 From: Cyrill Gorcunov Message-ID: <20200416121350.GR3072@uranus> References: <20200413094230.GC16266@atlas> <533bd68c-4bbb-446a-6265-da4f47d451f1@tarantool.org> <20200413194931.GB1734@tarantool.org> <8b7bcee8-b2db-8f2c-d241-687f6b6d6f4b@tarantool.org> <20200413213801.GB12552@atlas> <13d501d61286$af32d4b0$0d987e10$@tarantool.org> <20200414204127.GA32171@atlas> <2207FBB1-CFB8-4F68-BDED-8A2F4509B652@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 00/43] Unhide symbols List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org On Wed, Apr 15, 2020 at 11:58:06PM +0200, Vladislav Shpilevoy wrote: > >> > > This could be done with approach from @cyrillos, AFAIU. These functions > > should be annotated in the code, rather than collected in a separate > > list. > > Yeah, the problem is that there is no a compiler option, which would > prevent removal of certain unused symbols defined in static libraries, > when they are merged into one executable. Actually no, if symbols are reffered in executable they won't be vanished. Accessing symbols should be done in transparent way. IOW, I think of similar to kernel approach: - provide EXPORT_SYMBOL helper (macro which would put it into a section) - generate a special bootstrap routine which would access the cummulative symbols in the gathered section (linker must not drop it I think) But this is only ideas which I didn't dive into technical details yet and I refuse to do it in a rush! If this symbols are really that needed then Vladislav approach should do the trick and we could switch to another sheme transparently. > You can either export all of them using whole-archive option, or > export a list via the option used on the master branch now (but that > masks out all other symbols). > > Cyrill G. was referring to a kernel EXPORT_API macros. The problem is > it has nothing to do with compiler attributes. That macros generates a > special section for every function in assembly with a prefix __ksymtab Not for every, only for those which are market with EXPORT_SYMBOL[_x] > or something like that. That section contains the original symbol > reference + some meta. The meta actually is the virtual address and it is needed the kernel would test checksum on start to be sure that we're not corrupted. > https://github.com/torvalds/linux/blob/master/include/linux/export.h#L97 > > Then all such sections having the same prefix are merged into one big > section here: > > https://github.com/torvalds/linux/blob/master/scripts/module-common.lds > > And exported via a global array here: > > https://github.com/torvalds/linux/blob/master/kernel/module.c#L379 > > So essentially this is the same what I am doing, but using some assembly > and a linker script. > > Timur and Cyrill can correct me if I am wrong somewhere above. Yup, correct. > I would happy to implement something like that but looks like it is > not worth the complexity. As to me this is a way better in long term than current approach. I like to see immediately that some symbol is exported instead of stepping into extra/exports or whatever. But again, as I said I hate to do it in a rush and any scheme you provide now is ok for me sice we can change it transparently if we will. > > > If a function is not present in the tarantool binary - e.g. > > dropped as not used from static library - it should not be available > > anyways. Will it work you, Mons? > > All our public C API functions are defined in static libraries, and > many of them are not used in the executable nor used by FFI. And > still they should be available for dynamic user modules (.so, .dylib). Cyrill