rsb and toolchain debug symbols

[Chris Johns]

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.

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?

> 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