Re: Newbie back again...

[David Chisnall]

> On 19 Jun 2017, at 11:11, Richard Frith-Macdonald <address@hidden> wrote:
> 
> 
>> On 19 Jun 2017, at 10:10, David Chisnall <address@hidden> wrote:
>> 
>> On 24 Apr 2017, at 09:57, Richard Frith-Macdonald <address@hidden> wrote:
>>> 
>>> Setting variables in make is fairly straightforward, but I think only you 
>>> (and clang geeks) understand how these flags are actually supposed to work.
>>> 
>>> How are you supposed to turn use of the non-fragile ABI on/off  what flags 
>>> do you need to supply at compile time and what (if any) are supplied at 
>>> link time for
>>> a. building with the non-fragile ABI and
>>> b. building without non-fragile ABI
>> 
>> Non-fragile ABI is the default with all modern runtimes.  The correct way of 
>> specifying a runtime is with -fobjc-runtime={name}-{version}.  So, for a 
>> recent GNUstep runtime, you’d pass -fobjc-runtime=gnustep-1.7.  The compiler 
>> will then enable all of the features that it knows that this version of the 
>> runtime supports.  For example, it will use objc_msgSend on architectures 
>> where the runtime supports this, but use the two-stage lookup on other 
>> platforms.
> 
> Thanks ... that sounds clear but forgive me for wasting time 
> dopuble-checking;  We should remove support for specifying the 
> fragile/nonfragile option from gnustep make since it doesn't work on any new 
> systems?

Yes, probably.  That’s still supported in clang as a legacy compat option, but 
I think it just expands to the equivalent of something like 
-fobjc-runtime=gnustep-1.0.

> I'm happy with that (while I'd dearly like to be able to inspect variables 
> under debug without having to make explicit function calls to the runtime, 
> I'm sure people can live with that limitation).

It probably isn’t too hard to teach gdb to make those calls for you, if there’s 
someone we can persuade to do it.  I plan on looking at LLDB at some point, now 
it’s working reliably on non-Apple platforms as well.  The Apple runtimes have 
a bunch of functions that are intended to be called by the debugger that we 
don’t currently implement, which perform various operations without acquiring 
locks (on the basis that the debugger may have hit a breakpoint with the 
relevant lock held).  It’s probably worth my implementing them (or equivalents).

David