* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
@ 2014-03-27 21:01 ` fabian@ritter-vogt.de
2014-03-27 21:10 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fabian@ritter-vogt.de @ 2014-03-27 21:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #2 from Fabian Vogt <fabian@ritter-vogt.de> ---
It crashes and produces weird results if linked to bFLT.
If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist?
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
2014-03-27 21:01 ` [Bug c++/60691] " fabian@ritter-vogt.de
@ 2014-03-27 21:10 ` pinskia at gcc dot gnu.org
2014-04-02 16:55 ` fabian@ritter-vogt.de
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-03-27 21:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Fabian Vogt from comment #2)
> It crashes and produces weird results if linked to bFLT.
Yes because EABI is an elf only abi, if it does not have a place for the unwind
tables, then it is incompatible with the ABI :).
>If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist?
Because it is supported for some other targets, mainly windows based ones.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
2014-03-27 21:01 ` [Bug c++/60691] " fabian@ritter-vogt.de
2014-03-27 21:10 ` pinskia at gcc dot gnu.org
@ 2014-04-02 16:55 ` fabian@ritter-vogt.de
2014-12-12 15:19 ` ramana at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fabian@ritter-vogt.de @ 2014-04-02 16:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #4 from Fabian Vogt <fabian@ritter-vogt.de> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Fabian Vogt from comment #2)
> > It crashes and produces weird results if linked to bFLT.
>
> Yes because EABI is an elf only abi, if it does not have a place for the
> unwind tables, then it is incompatible with the ABI :).
Is it enough to put it (sorted/ordered) anywhere in the binary and point
__exidx_start (IIRC) and __exidx_end to the correct positions?
> >If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist?
>
> Because it is supported for some other targets, mainly windows based ones.
Hmm.. Windows RT? :P
Anyway, I had also reported the bug on binutils' bugzilla and the gas internal
error has been fixed. Nick even made a patch for gcc so it doesn't generate bad
asm anymore :-)
Bug report on gas: https://sourceware.org/bugzilla/show_bug.cgi?id=16765
Proposed patch: https://sourceware.org/bugzilla/attachment.cgi?id=7520
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
` (2 preceding siblings ...)
2014-04-02 16:55 ` fabian@ritter-vogt.de
@ 2014-12-12 15:19 ` ramana at gcc dot gnu.org
2014-12-12 15:30 ` fabian@ritter-vogt.de
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu.org @ 2014-12-12 15:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |ramana at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Fabian Vogt from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Fabian Vogt from comment #2)
> > > It crashes and produces weird results if linked to bFLT.
> >
> > Yes because EABI is an elf only abi, if it does not have a place for the
> > unwind tables, then it is incompatible with the ABI :).
> Is it enough to put it (sorted/ordered) anywhere in the binary and point
> __exidx_start (IIRC) and __exidx_end to the correct positions?
>
> > >If SJLJ isn't supported for ARM, why does --enable-sjlj-exceptions still exist?
> >
> > Because it is supported for some other targets, mainly windows based ones.
>
> Hmm.. Windows RT? :P
>
> Anyway, I had also reported the bug on binutils' bugzilla and the gas
> internal error has been fixed. Nick even made a patch for gcc so it doesn't
> generate bad asm anymore :-)
>
> Bug report on gas: https://sourceware.org/bugzilla/show_bug.cgi?id=16765
> Proposed patch: https://sourceware.org/bugzilla/attachment.cgi?id=7520
On ARM EABI, Linux GNUEABI the standard unwind tables are part of the ABI, sjlj
exceptions are not used and are likely to be completely bit rotten. There is
not much chance that this will work by default on ARM and neither is it going
to be standard configuration. Given this situation and that there is no
interest in this option on ARM I'm going to reject this bug.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
` (3 preceding siblings ...)
2014-12-12 15:19 ` ramana at gcc dot gnu.org
@ 2014-12-12 15:30 ` fabian@ritter-vogt.de
2014-12-12 15:35 ` redi at gcc dot gnu.org
2014-12-12 16:13 ` ramana at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: fabian@ritter-vogt.de @ 2014-12-12 15:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #6 from Fabian Vogt <fabian@ritter-vogt.de> ---
If sjlj exceptions are not supported for ARM, shouldn't the configure option be
invalid for ARM or at least print a warning?
If an option does exist and it simply crashes the compiler during make, it's
definitely broken and must be removed.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
` (4 preceding siblings ...)
2014-12-12 15:30 ` fabian@ritter-vogt.de
@ 2014-12-12 15:35 ` redi at gcc dot gnu.org
2014-12-12 16:13 ` ramana at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-12-12 15:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Just don't do silly things.
Just because an option exists doesn't mean you need to use it.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug c++/60691] Build fails in libstdc++ with --enable-sjlj-exceptions on ARM
2014-03-27 19:57 [Bug c++/60691] New: Build fails in libstdc++ with --enable-sjlj-exceptions on ARM fabian@ritter-vogt.de
` (5 preceding siblings ...)
2014-12-12 15:35 ` redi at gcc dot gnu.org
@ 2014-12-12 16:13 ` ramana at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu.org @ 2014-12-12 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #8 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Fabian Vogt from comment #6)
> If sjlj exceptions are not supported for ARM, shouldn't the configure option
> be invalid for ARM or at least print a warning?
> If an option does exist and it simply crashes the compiler during make, it's
> definitely broken and must be removed.
If that were a user option then yes, I agree.
If folks are building their own toolchains, they should know what they are
doing and not just use options because they think it may just work willy-nilly.
^ permalink raw reply [flat|nested] 8+ messages in thread