Eigenstate: myrddin-dev mailing list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Smaller binary size


Hi Ori,

I understand your points and they make sense.
Except, regarding the forbidding-unused-imports, I have a different opinion
but for now I can agree with you given that there isn't mature editors/IDEs
support available.

For the init calls topic, I am experimenting a solution inspired by the
Linux kernel module and U-Boot.
They solve the problem by collecting the address of the init symbols into a
dedicated section when linking.
When doing the initialization,  it loops over the 'vector' of function
pointers and calls them sequentially.
The init_array section of certain ELF files might serve the same purpose
but I am not familiar with it.

There might be some assumptions which must be met in order to make this
work properly but I decided to care about them later.


On 1 December 2017 at 16:55, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:

> On Fri, 1 Dec 2017 12:02:55 +0800, nml <arumakanil@xxxxxxxxx> wrote:
>
> > On 1 December 2017 at 11:28, Andrew Chambers <andrewchamberss@xxxxxxxxx>
> > wrote:
> >
> > > You don't need to split the code into smaller packages for smaller
> linking
> > > just into different .o files. Musl libc does this, the init calls are a
> > > different story though.
> > >
> > Hi Andrew,
> >
> > We can safely remove all the init calls asoocated with it if the package
> > can be proved to be unused,.
>
> Eh, sort of. This is hard. One example is libescfmt, but we also
> have hooks in libstd so that libthread can install mutexes. Is that
> a package being unused?
>
> So, yeah, if we don't even link the package, there's no __init__.
> But once there's a single 'use', the '__init__' needs to get called.
>
> > But within a package, we have to keep all init calls (and all their
> > downstream referenced symbols) even if the involed APIs are not used at
> > all.
> > For example, the hello-world doesn't need a DNS resolver but it has to be
> > kept because we cannot guarrantee if the init calls have any side-effect
> > and some APIs may depend on that.
> > That's why I started to think of fine-grained std at first.
> >
> > The lazy init approach that ori mentiioned earlier is a bit of ad-hoc to
> my
> > taste if I understand it correctly (That is, adding them to the entry
> point
> > of each API that depends on that init).
> > It's suitable for some scenarios but not all.
> > I am still comtemplating for a win-win solution that does not need to
> break
> > the std into pieces.
>
> Just as a heads up, I just implemented the lazy loading for the
> resolver -- it cut the binary size down significantly for a hello
> world program. Now, we're down to 95k of text, and 20k or so of
> data+bss. The vast bulk of that is to do with the formatting code
> pulled in by std.put.
>
> It's now pushed.
>
> --
>     Ori Bernstein
>

Follow-Ups:
Re: Smaller binary sizeOri Bernstein <ori@xxxxxxxxxxxxxx>
References:
Re: Smaller binary sizenml <arumakanil@xxxxxxxxx>
Re: Smaller binary sizeAndrew Chambers <andrewchamberss@xxxxxxxxx>
Re: Smaller binary sizenml <arumakanil@xxxxxxxxx>
Re: Smaller binary sizeOri Bernstein <ori@xxxxxxxxxxxxxx>