rsb and toolchain debug symbols

[Gedare Bloom]

On Sat, Aug 29, 2020 at 10:17 AM Michael Davidsaver
<mdavidsaver at gmail.com> wrote:
>
> On 8/27/20 5:31 PM, Chris Johns wrote:
> > On 28/8/20 5:39 am, Michael Davidsaver wrote:
> >> Is there a way to ask RSB to either build the toolchain
> >> (ie. gcc itself) without debug symbols, or to strip them
> >> prior to install?
> >
> > Not at the moment but this would be a nice feature. I can see it being needed.
> >
> >>
> >> https://github.com/mdavidsaver/rsb/releases/
> >>
> >> I keep a set of pre-built RTEMS pc*86 toolchains for use
> >> by CI builders, principally travis-ci.org.  In looking
> >> at adding RTEMS 5.1 to this I noticed that the resulting
> >> compressed tar was considerably larger that previously.
> >> 4.9 or 4.10 for pc386 are ~100MB, while 5.1 for pc686
> >> is weighing in at 380MB.
> >>
> >> Looking into it, most of this size seems to be in debug
> >> symbols.  eg. "libexec/gcc/i386-rtems5/7.5.0/cc1plus"
> >> is (uncompressed) 166MB with debug symbols and 26MB without.
> >
> > That is a saving. The RSB could scan the tree of files before coping them to the
> > install point and for any host executable run the host's `strip` command. I
> > suppose we could also run it on any host archives if there is any easy way to
> > detect them.
>
> strip -d <prefix>/libexec/gcc/*/*/cc1*
> strip -d <prefix>/bin/*
>
> Gives ~50% reduction in compressed and uncompressed sizes without much effort.
>
> > A tool chain also installs the various libc, libm, libstd++ etc libraries for
> > the RTEMS architecture. With an expanding number multilibs in some architectures
> > the number and so the overall size of those libraries is growing. I am not sure
> > if we can do something about that. Stripping them would help but this leaves you
> > with RTEMS executables that have no debugging info. Would that be an issue?
>
> I'd prefer to keep debug symbols for target code.
>

Yes, this seems likely to be better to strip at the end of application
builds, if desired. Maybe it is possible to tune the toolchain for the
particular multilibs of interest for a given user's setup though? If
someone is only going to build one particular ARM board, they don't
need all the many arm multilibs.

> >> Also, I installed the following packages to a clean
> >> ubuntu 18.04.5 image in order to build.  This release
> >> doesn't install /usr/bin/python by default (just 'python3').
> >> The GDB build seems to handle this just fine, but the
> >> rtems-tools build errors when it can't run 'python'.
> >
> > This is a complex issue with no simple solution for users that we can see. I
> > have raised a ticket for this against the 5.2 milestone:
> >
> > https://devel.rtems.org/ticket/4064
> >
> > We have been discussing this topic in:
> >
> > https://devel.rtems.org/ticket/4037
> >
> > The `waf` part of the discussion is relevant here. The RSB can be considered a
> > "user" and so it needs to manage the lack of a `python` command.
> >
> >> bison
> >> flex
> >> texinfo
> >> unzip
> >> git
> >> python3-dev
> >> python-dev
> >
> > I do not think adding a check to `sb-check` is the answer, I think having the
> > RSB invoke `waf` as `python3 waf ...` is the best solution but I need to teach
> > it to do this.
> >
> > As a work around if you create a virtual environment to build the tools in using ...
> >
> >  python3 -m venv rtems-rsb
> >  . ./rtems-rsb/bin/activate
> >
> > ... you should have a `python` command in your path. I consider this a work
> > around to an RSB fix but it is something you can do now.
> >
> > I have added this documentation about this to the user manual on `master`, maybe
> > it should be ported onto the 5 branch?
> >
> > Chris
> >
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users