Re: M1 port: Call for funding

Thanks for the gdb advice. I agree, a “vanilla” debugger will be easier for all involved.

I am “a Mac person” but, at the risk of religious ire, my plan is to port to Linux first. If you disagree for technical reasons, let me know. I own a “maxed out” late 2013 MacBook Pro, I can’t afford to buy an M1 for me and my intern, plus donations would be better spent on labor. 

--Tim

> On Jan 2, 2024, at 03:09, R. Matthew Emerson <[email protected]> wrote:
> 
> 
> 
>> On Jan 1, 2024, at 5:50 AM, Tim McNerney <[email protected]> wrote:
>> 
>> Yes! I would enthusiastically attend a “just bump the fasl version number” (i.e. null upgrade) bootstrapping class.
>> 
>> Modifying gdb so that it recognizes Lisp objects could help quite a bit (e.g. headers, type bits, etc). When I was at Harlequin, I modified gdb so it better displayed Dylan stack frames (and hid internal ones), and that wasn’t such a heavy lift, even for someone who’d never hacked gdb before.
> 
> The strategy we’ve used to date is to implement a printer for lisp objects in C. See the files like lisp-kernel/x86_print.c (and ppc_print.c, etc.).
> 
> Then, you put something like the following in your .gdbinit:
> 
> define pl
> call print_lisp_object($arg0)
> end
> 
> There’s a .gdbinit in lisp-kernel/linuxx8664/.gdbinit that might be interesting to look at.
> 
> This approach gets you pretty far, and you don’t have to modify the debugger source code.
> 
> Old tips: https://trac.clozure.com/ccl/wiki/CclUnderGdb
> 
> Of course, Apple’s provided debugger is now lldb.  It used to be possible to install gdb on an Intel-based Mac, but I don’t know if gdb has been made to work with Apple silicon Macs. (A quick web search makes me think it probably hasn't.)
> 
>