Replace -g flag by -gdwarf-4 for musl armhf toolchain [AP-3099]

[sbmueller]

The binutils version of the toolchain seems to be too old for the compiler, expecting DWARF5. This change enforces DWARF4.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100725

[sbmueller]

@swift-nav/build ping

[jbangelo]

@sbmueller could you give a bit of context for this change? Are there certain toolchains being used that need DWARF-4 debug symbols specifically? Why only on the ARM toolchain?

How do we test bazel rule changes like this to avoid breaking builds?

[sbmueller]

@jbangelo sure. I'm working on https://swift-nav.atlassian.net/browse/AP-3099. The goal of the ticket is to resolve the CI errors in this job. One of those errors is:

/home/jenkins/.cache/bazel/_bazel_jenkins/cc4b846586278eecd893264d08018579/external/arm-linux-musleabihf/bin/../lib/gcc/arm-linux-musleabihf/11.2.0/../../../../arm-linux-musleabihf/bin/ld: DWARF error: can't find .debug_ranges section.

The Jenkins file for the stage is here, using the Docker image 571934480752.dkr.ecr.us-west-2.amazonaws.com/swift-build-bazel:2024-05-29, wich is a Debian 11 container.
As described in the link in the description, the error is due to a binutils version < 2.35. In the musl armhf toolchain, 2.33.1 is used.
Therefore, I simplly applied the fix suggested in the thread. I tested it in the original job and the error is resolved.

In terms of how to test, I was hoping to get more insight from discussions in this PR where this toolchain is used. I'm unfamiliar with everything around the build-working-group yet. If you have other ideas how to fix the error, I'm also happy to have a look. I guess one could also update the MUSL toolchain to binutils >= 2.35, but that seemed like the higher impact change to me.

[jbangelo]

Looking around I only see this particular toolchain used in one place, so if your build is fixed by this I don't see a risk of other builds getting impacted.

I do find it odd that the the toolchain we're using here isn't packaged with a matching version of binutils. I have seen something like this happen when you mix different compiler versions and whatever version of binutils your chosen distro packages, but I was under the impression that the ARM toolchain we're using here is completely self contained. Maybe that's not actually the case? Either way I think this is a pretty low risk change.

Thanks for providing the additional context @sbmueller !