> On Aug 3, 2021, at 2:39 PM, Iain Sandoe <idsan...@googlemail.com> wrote:
> 
> 
> 
>> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches 
>> <gcc-patches@gcc.gnu.org> wrote:
>> 
>>> On Aug 2, 2021, at 5:09 PM, Eric Gallager <eg...@gwmail.gwu.edu> wrote:
>>> 
>>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>> 
>>>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 
>>>> crashes,
>>>> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions 
>>>> (which
>>>> Darwin does).
>>>> 
>>>> This patch makes the general case not crash.
>>>> 
>>>> I don't have commit access, so if this patch is suitable, I'd need someone 
>>>> else
>>>> to commit it for me.  Thanks.
>>> 
>>> Is there a bug open for the issue that this fixes? Just wondering for
>>> cross-referencing purposes...
>> 
>> No, I didn’t file a bug for this one, just sent the patch directly.  Hope 
>> that’s OK.  If not, happy to file one.
> 
> I have this on my TODO (and in my “to apply” patch queue - IMO it’s OK as an 
> interim
> solution - but I think in the longer term it would be better to make 
> fobjc-sjlj-exceptions
> into a NOP, since the exception models are fixed for NeXT runtime (unless you 
> have
> some intent to update the 32bit one to use DWARF unwinding ;-) ).

Thanks.

It certainly isn’t crystal clear just from the diff in the mail, but with this 
patch, -fobjc-sjlj-exceptions *is* essentially a no-op (modulo a small warning) 
under NeXT v2.

Prior to this patch, it’s also a no-op, but (a) it’s initially on by default 
for NeXT v2, which (b) causes a crash unless `-fobjc-exceptions` is also 
specified.

Matt

Reply via email to