add options for workflows with strip and debug symbols

[deitch]

Attempts to address the conversation beginning with this comment.

Provides options to reusable workflows to build:

• with/without debug symbols
• with/without stripped binaries

By default, it behaves like today: with debug symbols, without stripping binaries. However, if you pass it options, for example [true, false] for each, then it will build both with and without. That means you could have up to 4 distinct build artifacts: debug+not stripped; not debug+not stripped; not debug+stripped; debug+stripped. The last doesn't make much sense, as strip usually removes debug symbols, but is an inevitable result of a 2x2 matrix of options.

We could simplify this by just having two options: debug and not debug, which removes the overwhelming majority of size of the binaries, as pointed out by @TommyMurphyTM1234 in this comment. Or we could just have 2, stripped (no debug+ stripped) and not stripped (with full debug).

The downside to the way I implemented this, is that you end up with 4 possible builds. But for any stripped options (debug+stripped, no debug+stripped), you might as well reuse the previous build and just strip symbols. That would take about a minute, rather than the hours of build.

PR is open for discussion, so we can find the best way.

[deitch]

My personal view would be for simplicity, just two options:

• debug+unstripped (current default)
• stripped

This way:

• someone sends [false], it builds like today, creates unstripped artifact
• someone sends [true], it builds like today and then strips, saves stripped artifact
• someone sends [true,false] (or vice versa), it builds like today, saves unstripped artifact, then strips and saves stripped artifact

If each build run took 60 seconds, I wouldn't care; with potential hours, it matters.

Definitely open to input.

[deitch]

Job failed due to disk space. Unfortunately, I don't have permissions to restart the failed jobs. Can I trouble you @cmuellner ?

[deitch]

FWIW, I ran an experiment. I downloaded one of the most recent tar archive artifact from a nightly. And then I just ran strip on every file. Yes, it could have been more efficient - validate that it is the right file type, etc., no point in running strip on python files or .h headers - but it was quick and dirty.

$ docker run -it --rm -v $(pwd):/pwd ubuntu:24.04
# apt update -y && apt install -y binutils
# cd /pwd
# find . -type f -exec strip {} \;

When I was done, all of the executables were marked as stripped (no debug symbols), and the whole thing had shrunk dramatically.

That took about a minute.

I did not

Do we want to go down that path for this? Something like:

1. Compile as currently
2. If strip not set, or strip and unstripped, create the tar archive
3. If strip set (or strip and unstripped), run the strip I just did, create a separate tar archive

I don't mind doing that, if we think it is valid.

[cmuellner]

If you don't want to have four possible stripping/debugging combinations, you could use a type: choice parameter to restrict the possible options.

[cmuellner]

Regarding declare-stripping-at-configure vs. post-build stripping with find:
I don't mind either. The effect will be similar (someone who cares may do the measurement).
The only thing that I require is, that we have a single mechanism for building a toolchain with stripped binaries (having a configure-based mechanism and a post-build-find/strip-command is too much redundancy).

[deitch]

I don't mind either. The effect will be similar (someone who cares may do the measurement).

In that case, I will see if I can update the PR to do it post-build, as it is orders of magnitude more efficient.

at we have a single mechanism for building a toolchain with stripped binaries (having a configure-based mechanism and a post-build-find/strip-command is too much redundancy)

From a user perspective, we can leave it the way it is, via configure --enable-strip (or not). CI can do it differently, since we may want to build both.

Or we can have a make option for it. We already run configure followed by make, it is not too hard to have another option to make, which means you would not need it in configure.

I am going to try to get the PR to do it the efficient way, but also run some experiments locally.

[deitch]

OK, I redid the CI. I couldn't use type: option, as that is available for workflow_dispatch, but not workflow_call. Oh well.

What I did:

• added an option strip with type: string, but it enforces (and comment says) it must be one of stripped, unstripped or both
• added an early job to enforce it (we can reuse the job to enforce other things later, if it becomes useful)
• build the artifacts as usual
• if unstripped or both, create the tar file riscv.tar.xz
• if stripped or both, strip the binaries and create the tar file riscv-stripped.tar.xz
• creates 2 toolchain names: same as now, plus one with -stripped in it
• if unstripped or both, upload properly named artifact (from previous step) from the tar file riscv.tar.xz
• if stripped or both, upload properly named artifact (from previous step) from the tar file riscv-stripped.tar.xz

I think this hits the requirement nicely. Would be good to get your input.

[deitch]

Ran into no space issues again. Aren't GitHub Actions runners fun? Can you restart please @cmuellner ?

[deitch]

I cannot tell why make report failed.

[cmuellner]

I cannot tell why make report failed.

The logs say:

mkdir: cannot create directory ‘/mnt/riscv/sysroot’: No space left on device

I restarted all failed jobs.

[deitch]

Thanks

[deitch]

Some errors in my action file. Fixed and pushed, we can let it run and see.

[deitch]

They all passed, CI is green! 😄

[deitch]

Good morning @cmuellner . How is this approach? Anything you need changed on it?