Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:

> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rather than their real senders?
> > This has become very annoying recently.
> 
> Yes, for emails from domains with declared interest in email
> cleanliness, via DMARC records in DNS.  We have observed mail
> -blocked- at third parties, even just days ago, when we failed to
> sufficiently authenticate outgoing reflected emails.
> 
> AIUI, all this effort is driven by wanting to defeat not just spammers
> but also real security problems like phishing enabled by forgery,
> including specifically the From: header.

 And it has actually broken GCC's patchwork: 
, which I used to use to 
track my patches.  Now I cannot do that anymore as patches submitted from 
my WDC address are marked as coming from , which 
obviously means they are not attributed to me.

 I am fairly sure it breaks `git am' too, requiring a `From' override in 
the change description for author attribution in patch application to work 
reliably (I tend to work on my outbox when applying my own patches, so I 
avoid this issue, but I am sure the issue will hit someone sooner or 
later).

 And of course I cannot use the `macro@' pattern anymore to select mailing 
list messages in my inbox that I sent myself.  Frankly it's the least of 
the annoyances, but still, and they all add up.

 This is all silly, requiring the SMTP envelope sender to match the `From' 
header breaks even the most basic e-mail mechanisms like the use of a 
`.forward' file.  Can we please do something about it?  Is functional 
regression the price we absolutely need to pay for progress?

 How come the Linux kernel people who do e-mail patch management on a 
vastly larger scale than we do, both in terms of traffic and the number of 
mailing list subscribers, can get away without all these odd quirks in 
their list server management?  Perhaps it would be good asking them how 
they handle their stuff?

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

Hi Frank,

> >  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> > the change description for author attribution in patch application to work 
> > reliably (I tend to work on my outbox when applying my own patches, so I 
> > avoid this issue, but I am sure the issue will hit someone sooner or 
> > later).
> 
> That part is at least pretty easy: use
>   git format-patch --from "Real Name git "
> which will then force a second fake From: header into the body of
> the commit email, where git-am can find it.

 Sure, there are various ways to deal with that, both on the sender's and 
the receiver's side, however all require a manual intervention and are 
therefore prone to a human error.  Which will obviously happen sooner or 
later.

> > This is all silly, requiring the SMTP envelope sender to match the `From' 
> > header breaks even the most basic e-mail mechanisms like the use of a 
> > `.forward' file.  [...]
> 
> Unfortunately naive .forward based forwarding looks exactly like faked
> or spam email to a third party MTAs.

 And can certainly score a positive though not a definite rating in spam 
qualification.  I don't think we ought to encourage bad IT management 
practices by trying to adapt to them too hard and hurting ourselves (our 
workflow) in the process.

> > How come the Linux kernel people who do e-mail patch management on a
> > vastly larger scale than we do, both in terms of traffic and the
> > number of mailing list subscribers, can get away without all these
> > odd quirks in their list server management?  [...]
> 
> I'm not sure, but their mails tend to be laden with a vast number of
> Cc:'s, which bypass mailing list reflectors.

 Surely all the bots receive messages via a mailing list subscription 
though.  Cc's are solely for maintainers, reviewers or other explicitly 
interested parties.  Some maintainers actually require submissions to come 
via the relevant mailing list rather directly to them.  Somehow it works.

 Thank you for your input regardless!

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 7 Apr 2020, Christopher Faylor wrote:

> >Can we please switch it off?  It's not like we really had a problem before 
> >the switch to mailman.
> 
> You can't really make statements like this which imply that you are
> aware of "problems" on sourceware when you're not a sourceware
> administrator.
> 
> We actually were munging the From on the old server and we were getting
> an increasing number of complaints to postmaster that people weren't
> receiving mail.

 Hmm, methinks these really ought to be bounced to the postmaster of the 
broken receiving site.  It is not that sourceware has been actually doing 
anything specific to make the recipient's MTA refuse e-mail.  Even if some 
spam prevention has been installed to block some kind of e-mail, whoever 
requested some kind of e-mail traffic need to have a way to whitelist the 
traffic requested, and I believe all list server software provides means 
for the recipient to identify the source, such as a `List-ID' header or 
suchlike.

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 7 Apr 2020, Christopher Faylor wrote:

> >In a way that's amusing and just reinforces my p.o.v. that DMARC is 
> >bollocks.
> 
> Not that it means anything but I agree 100%.
> 
> It's like whoever made the "standard" just said "to hell with mailing
> lists".

 Maybe they just didn't know of their existence.  Seriously.

 I have actually been more and more astonished recently with the discovery 
of people living in some kind of a parallel reality of Internet standards 
and practices, who never heard of solutions and habits I have known since 
forever and considered obvious.  Especially as we now have an entirely new 
generation of IT people who never actually saw the Internet like it was 
back in 1990s and earlier on, simply because it was before they were born.

 Consequently things that used to work since forever start breaking and 
people you report such breakage to have no clue as to what you're talking 
about.

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 14 Apr 2020, Christopher Faylor wrote:

> >I think that means that dmarc_moderation_action: "Munge From" can
> >simply be switched off then (at least I don't see which other headers
> >e.g.  gcc@ is rewriting that would cause DMARC to scream; and if there
> >are any, then it would be better to disable those as well.  Same with
> >any potential body rewriting that might still happen).
> 
> It can't be switched off if we strip html attachments.

 Based on current usage would instead plain rejecting e-mail with any HTML 
attachments be a viable way to move forward?

> >I would offer help testing that this doesn't cause delivery issues, e.g. 
> >on some test email list, but it seems none of my domains is DMARC-infected 
> >:-/
> 
> Nevertheless, offers of help are appreciated (and rare).  :-)

 I'm in a `p=none' domain at this e-mail address, so technically I would 
say it has been quite reasonably configured and therefore none of our 
people should have to choose between suffering from `From' munging or 
persuading the postmasters to change the configuration or switching to 
another MTA for mailing list submissions.

 Therefore I'd be happy to participate in testing a solution for disabling 
`From' munging for `p=none' domains.

  Maciej

Re: Help, Where I can find proper libtool version?

[Maciej W. Rozycki via Gcc]

On Wed, 15 Apr 2020, 易会战 via Gcc wrote:

> I am trying to add a library into gcc source code tree. The gcc source 
> have used libtool 2.2.7a 1.1334. but I cannot find the version.

 It is "libtool (GNU libtool 1.3134 2009-11-30) 2.2.7a" AFAICT, that is 
1.3134 rather than 1.1334.  I take it there has been a typo there.

> So after runing autoreconf and make , I get "libtool: 
> Version mismatch error.".It is a curious version, the gnu 
> mirrors have no such version.

 It is a repository snapshot, there has been no such release.  For 1.3134 
you need to check out commit 2c9c38d8a12e ("Please C++ compilers when 
calling strrchr.") from the libtool Git repository.

 FWIW I think it would be good having a tarball of this snapshot, 
preferably made with `make dist' so that all the generated pieces are 
there, hosted somewhere, such as  or maybe 
 (there might be a better place).  Moving on to an 
actual libtool release, preferably less than 10 years old, would I think 
be a viable alternative too.

 HTH,

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Wed, 13 May 2020, Rainer Orth wrote:

> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
> 
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually kills them.

 Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
fix for the bug you mean?

 Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
very week I have been chasing a phenomenon with Expect's `wait' semantics 
causing a reliable hang in remote testing if `ssh' to the target board 
stops responding for whatever reason.  I have come up with a solution 
(that I'd be happy to upstream, except that DejaGNU maintenance seems to 
have been dead for like a year now), which I have also confirmed to be 
required with current DejaGNU Git master so it must be a different one, 
and I would like to know how it might be related to the bug you mention.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

Hi Rainer,

> >  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> > very week I have been chasing a phenomenon with Expect's `wait' semantics 
> > causing a reliable hang in remote testing if `ssh' to the target board 
> > stops responding for whatever reason.  I have come up with a solution 
> > (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> > have been dead for like a year now), which I have also confirmed to be 
> > required with current DejaGNU Git master so it must be a different one, 
> > and I would like to know how it might be related to the bug you mention.
> 
> I believe it's
> 
> commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
> Author: Richard Biener 
> Date:   Fri Jul 6 21:35:29 2018 +1000
> 
> * lib/remote.exp (close_wait_program): Use separate kill command
> for each pid.
> 
> Richard pointed me at the 1.6.2 release when I mentioned the issue
> somewhere on a gcc list, and it's his patch, so it's likely to be the
> one.

 Thanks; I have seen it and even backported it to my test environment.  
It does not affect my scenario at all however as the kill commands get 
killed just as Expect's `wait' succeeds and then the subsequent TCL 
`close' invocation made on the pipeline in the caller hangs on wait(2) 
indefinitely.  So it's all the same area, but different modes of failure.  
I'll wrap up on my patches then and post them soon.

> It went into DejaGnu immediately after the 1.6.1. release ;-(

 Well, 1.6.2 has been out for a while now so I guess distros might well 
upgrade.  I think it's one of those packages there is not need with to 
wait for code to settle, as it's for core developers' use.  OTOH it's not 
a big deal for the intended users to check out and install the top of 
trunk version anyway.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

 Thank you for your contribution to DejaGnu over the years and for your 
input on this occasion.

 However it does not appear to me to be right that Tcl is not maintained, 
as a stable 8.6.10 release has been made as recently as half a year ago. 
And then current development appears ongoing, ferociously indeed, with the 
last check in literally today (barring my time zone), as indicated here: 
.

 Other than that what would be the technical advantage from rewriting 
DejaGnu in Python (/me asking as a Python ignoramus)?

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Right now working through patches is probably more important. :-)
> There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
> submit them so I don't have to dig them out of email archives.

 I have reposted the single patch I have had outstanding.  Please review.  
I have a couple of new ones down the line.

 Overall perhaps a patch management system might be good having to make 
chasing patches easier, such as patchwork, and we already use Git, so we 
are set for using that tool.  Siddhesh has recently installed version 2.0 
for glibc and migrated all the old patchwork data, and might be able to 
give us some input.

 Siddhesh, would you care to tell us how much effort it would be to set up 
fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
it is with glibc, and there would be no data to migrate (but we might want 
to feed a couple of months' back worth of mailing list traffic).

 Just a suggestion.  See:  to get a 
feel.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Sat, 16 May 2020, Rob Savoye wrote:

> >  Overall perhaps a patch management system might be good having to make 
> > chasing patches easier, such as patchwork, and we already use Git, so we 
> 
>  As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu,

 Hmm, as a youngster who's been around for twenty-something years only (my 
first patch was for glibc, back in 1998) I haven't even heard of this 
patch service before.  It doesn't appear linked to our mailing list either 
and instead you need to go through the hoops of a web interface (and open 
an account first) to submit a change.

> Our
> bug tracker is there their too. We've used that for a long time. Yes,
> patches in email are harder to track.

 That's precisely what patchworks is for, which has been used to various 
extent for the GNU C library, GCC and GDB already.  All of which projects 
are of similar vintage to DejaGnu and I reckon rather important for the 
GNU project.  Given that our main patch submission channel is e-mail, 
what's the point in using a system that does not accept one?

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

>   I processed the patch backlog for DejaGnu, and have gone through the
> bug list. It'd be nice if somebody could try master with a more complex
> environment, etc... if I'm going to push out a release. For cross
> testing all I have is a PI and QEMU.

 I'll run some RISC-V remote GCC/GDB testing and compare results for 
DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
many hours to go through these testsuite runs.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

> >  I'll run some RISC-V remote GCC/GDB testing and compare results for 
> > DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
> > many hours to go through these testsuite runs.
> 
>   That'd be great. I'd rather push out a stable release, than have to
> fix bugs right after it gets released.

 I have completed GCC and GDB testing now with the `riscv64-linux-gnu' 
target and the `x86_64-linux-gnu' host.

 GDB results obtained with real hardware are looking good, with the usual 
fluctuation due to intermittent failures caused by races in test cases:

@@ -63343,8 +63344,8 @@

=== gdb Summary ===

-# of expected passes   59902
-# of unexpected failures   778
+# of expected passes   59900
+# of unexpected failures   781
 # of unexpected successes  2
 # of expected failures 48
 # of unknown successes 5

 Similarly GCC test results taken with QEMU in the user emulation mode 
show a couple of intermittent discrepancies (not present on a rerun) 
within the libgo testsuite only:

@@ -912,12 +912,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-FAIL: database/sql
+PASS: database/sql

=== libgo Summary ===

-# of unexpected failures   1
-Test run by macro on Thu Jun  4 04:29:42 2020
+# of expected passes   1
+Test run by macro on Wed Jun  3 01:38:10 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

and:

@@ -2239,12 +2239,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-PASS: net/http/pprof
+FAIL: net/http/pprof

=== libgo Summary ===

-# of expected passes   1
-Test run by macro on Thu Jun  4 02:42:17 2020
+# of unexpected failures   1
+Test run by macro on Tue Jun  2 23:54:18 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

(the testsuite is run in a peculiar manner in the remote case, hence the 
individual per-test summaries) and are otherwise identical.

 However native `x86_64-linux-gnu' GDB testing does not work at all; all 
it gets is:

get_compiler_info: default_target_compile: No compiler to compile with
get_compiler_info: compiler_info not provided
get_compiler_info: got unexpected diagnostics
get_compiler_info: unknown
gdb compile failed, default_target_compile: No compiler to compile with

Conversely all things being equal DejaGnu 1.6 finds native `/usr/bin/gcc' 
just fine:

get_compiler_info: set compiler_info "unknown"
get_compiler_info: set compiler_info [join {gcc 9 2 1} -]
get_compiler_info: gcc-9-2-1

and in the verbose mode also:

Checking /home/macro/bin for gcc
Checking /home/macro/bin for gcc
Checking /usr/local/bin for gcc
Checking /usr/bin for gcc
Choosing /usr/bin/gcc

I ran a quick bisection and the culprit turned out to be:

ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer 
Date:   Mon May 25 08:40:46 2020 -0600

 Establish a default C compiler by evaluating [find_gcc] if no other 
compiler is given.

 So this regression has to be fixed before any new release is made.

 HTH,

  Maciej

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[Maciej W. Rozycki via Gcc]

[cc-ing Joel as the originator, and ]

On Tue, 9 Jun 2020, Jacob Bachmeyer wrote:

> >> I ran a quick bisection and the culprit turned out to be:
> >>
> >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
> >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044
> >> Author: Jacob Bachmeyer 
> >> Date:   Mon May 25 08:40:46 2020 -0600
> >>
> >>  Establish a default C compiler by evaluating [find_gcc] if no 
> >> other compiler is given.
> >>
> >>  So this regression has to be fixed before any new release is made.
> >
> > I will look into this.  So far, I have confirmed that the problem does 
> > occur and that setting the "compiler" board_info key in 
> > baseboards/unix.exp seems to avoid it.  It looks like the default is 
> > not being selected in all cases where it should be used.  I still need 
> > to find the exact problem to write a regression test to isolate this 
> > bug and make it stay squashed.
> 
> After further efforts, and a few hours wasted trying to figure out why 
> additional tracing code added to default_target_compile was not 
> producing output, I eventually decided to just make 
> default_target_compile throw a Tcl error -- and I did not get a Tcl 
> error when running the tests...
> 
> That is "very interesting" and a quick grep -R reveals the culprit:  the 
> GDB testsuite is overriding default_target_compile in 
> gdb/testsuite/lib/future.exp.  Comments indicate that that file was 
> intended to temporarily bundle certain features with the GDB testsuite 
> that had not yet been merged into upstream DejaGnu -- in 2004.  Now 
> DejaGnu core is continuing to develop, leaving the old code copied into 
> the GDB testsuite broken, and making this NOTOURBUG.

 Well, as the name suggests (regrettably there's no adequate documentation 
there) this procedure is there to be overridden.  The way it's done in GDB 
might perhaps be non-standard, as the standard way AFAICS would be by 
providing a `gdb_compile' handler, but I think this is tangential, and the 
chosen solution is there possibly because DejaGnu had no `${tool}_compile' 
knob back then (I haven't checked).  That does not really matter though, 
as the net effect would be the same.

> In short, this is not a regression in DejaGnu; this is code duplicated 
> into the GDB testsuite that was slated for removal from that location 
> years ago and needs to be removed from the GDB testsuite, or at least 
> made conditional on running under a version of DejaGnu old enough to 
> require it, if such versions are still supported for running the GDB 
> testsuite.  If that code has added features not present in upstream 
> DejaGnu over the years, now is the time to get those patches in.

 Well, it clearly is a functional regression as the interface has changed, 
even if not a formal one, and I would consider it a release stopper.

 As it happens there are about 2 users of DejaGnu there, which means any 
fatal regression would have been easily caught in the course of change 
verification (and running binutils/GDB and GCC test suites natively is 
about as easy as it can be: `configure && make && make check'), and indeed 
should have, and then sorted with the respective communities if indeed the 
interface change is unavoidable, with a transition period so that the 
users can prepare changes to their frameworks, including backports to 
various release branches if applicable, before the old interface is 
removed from DejaGnu.  My suggestion would be to revert the change, get 
the details sorted with GDB people and only reapply it when all parties 
are ready. 

 Anyway, I have completed the verification I have volunteered to do and 
therefore I'm done with my part.  Please sort it between the communities.  
I have other stuff to do I have committed to.

  Maciej

RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)

[Maciej W. Rozycki via Gcc]

On Sun, 12 Jul 2020, Maciej W. Rozycki wrote:

>  I don't think we have a way to redirect the reference to `__GI_memset'.

 Additionally, I need to mention that where `libgcc.a' has been built at 
`-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free' 
references from numerous `libgcc.a' objects.  This is because those 
objects pull in the exception unwinder; specifically `__divdi3', 
`__moddi3', and `__umoddi3' all include a call to `_Unwind_Resume' each.

 Arguably this might probably be called a deficiency in libgcc, however 
the objects are built with `-fexceptions -fnon-call-exceptions' and at 
`-O0' GCC might not be able to see through code that no exception may 
happen there.  Therefore I am not sure offhand if this needs to be 
considered a GCC or glibc bug.

  Maciej

.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`init_dwarf_reg_size_table':
.../src/gcc/libgcc/unwind-dw2.c:1572: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_init_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1613: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_install_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1694: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind-dw2.c:1711: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`_Unwind_ForcedUnwind_Phase2':
.../src/gcc/libgcc/unwind.inc:152: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind.inc:163: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `_Unwind_DeleteException':
.../src/gcc/libgcc/unwind.inc:281: undefined reference to `free'
collect2: error: ld returned 1 exit status
Makefile:554: recipe for target '.../obj/glibc-boot/ilp32/elf/ld.so' failed
make[2]: *** [.../obj/glibc-boot/ilp32/elf/ld.so] Error 1

Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

[Maciej W. Rozycki via Gcc]

On Tue, 14 Jul 2020, Richard Biener wrote:

> > >  Arguably this might probably be called a deficiency in libgcc, however
> > > the objects are built with `-fexceptions -fnon-call-exceptions'
> >
> > I consider that broken.  It doesn't make any sense to build a lowlevel
> > runtime library like libgcc with exceptions.
> 
> Indeed - you only need to be able to unwind through those, so
> -fasynchronous-unwind-tables should be used.

 This is libgcc's default however, only overridden for a couple of ARM 
targets, for the very reason to avoid pulling in the unwinder, according 
to the associated comments.  This was added with commit fc6aa0a98a0c some 
3 months before commit b932f770f70d added `-fasynchronous-unwind-tables' 
as a supported compiler option, all back in 2001, so we've had it for 
quite a while now.

 The RISC-V target doesn't appear to produce any division overflow traps, 
which would necessarily have to be arranged by a software convention like 
with, say, the MIPS target, as the relevant hardware instructions do not 
trigger an exception under any conditions.

 By switching to `-fasynchronous-unwind-tables' the ARM override can also 
go presumably, right?

  Maciej