Just got finished downloading SVN 1752 and recompiling.
The Backtrace::show_item() code seems to work fine on both Linux (Fedora 39
x64) and macOS (Sonoma 14.3.1 Apple Silicon).
macOS:
⎕FIO ¯16
==============================================================================
Assertion failed: 0 && "Simulated Assert() (aka. ⎕FIO ¯16)"
in Function: eval_B
in file: Quad_FIO.cc:1191
C/C++ call stack:
*** useless apl.lines (no CXXFLAGS=-rdynamic -gdwarf-2)
----------------------------------------
-- Stack trace at Assert.cc:75
----------------------------------------
0x1026570bc main
0x1028759e8 Workspace::immediate_execution(bool)
0x1026c8660 Command::process_line()
0x1026c8964 Command::process_line(UCS_string&, std::__1::basic_ostream<char,
std::__1::char_traits<char>>*)
0x1026cc128 Command::do_APL_expression(UCS_string&)
0x1026e0954 Command::finish_context()
0x102700600 Executable::execute_body() const
0x1027fbc28 StateIndicator::run()
0x102751e70 Prefix::reduce_statements()
0x10274ece8 Prefix::reduce_MISC_F_B_()
0x1027a4134 Quad_FIO::eval_B(Value_P) const
0x10267d240 do_Assert(char const*, char const*, char const*, int)
========================================
SI stack:
Depth: 0
Exec: 0x600001860000
Safe exec: 0
Pmode: ◊ ⎕FIO ¯16
PC: 3 (4) RETURN_STATS
Stat: ⎕FIO ¯16
err_code: 0x0
Fedora 39 x64:
⎕FIO ¯16
==============================================================================
Assertion failed: 0 && "Simulated Assert() (aka. ⎕FIO ¯16)"
in Function: eval_B
in file: Quad_FIO.cc:1191
C/C++ call stack:
*** useless apl.lines (no CXXFLAGS=-rdynamic -gdwarf-2)
----------------------------------------
-- Stack trace at Assert.cc:75
----------------------------------------
0x7f1971a4620b __libc_start_main
0x7f1971a4614a
0x472a6a main
0x60aa25 Workspace::immediate_execution(bool)
0x4d517d Command::process_line()
0x4d5961 Command::finish_context()
0x4e2087 Executable::execute_body() const
0x59a610 StateIndicator::run()
0x5210b1 Prefix::reduce_statements()
0x51e3d5 Prefix::reduce_MISC_F_B_()
0x55e65e Quad_FIO::eval_B(Value_P) const
0x4884dc do_Assert(char const*, char const*, char const*, int)
========================================
SI stack:
Depth: 0
Exec: 0xbb6d40
Safe exec: 0
Pmode: ◊ ⎕FIO ¯16
PC: 3 (4) RETURN_STATS
Stat: ⎕FIO ¯16
err_code: 0x0
One small item. Appreciate the credit on the copyright notice in Backtrace.cc
for SVN 1752. But I'd suggest not including "(Apple)" on the notice as I am not
associated with Apple.
I would not want them to have any copyright claim on the code I submitted to
you. That code was engineered by examining the output of the macOS system
library function (which, by the way they did not document the string format),
and not by referencing any Apple-provided examples.
- Paul
> On Feb 13, 2024, at 9:35 AM, Paul Rockwell <paulrockw...@mac.com> wrote:
>
> Jürgen,
>
> I’ll download and test SVN 1752 on both macOS and a Fedora Intel system I
> have hanging around. I figured you don’t use a Mac, so that’s why I took it
> upon myself to exercise some dormant coding skills and provide the diffs.
>
> The macro __APPLE__ is a system defined macro for macOS. I will find which
> system defined header file it resides in. It was recommended by some research
> to provide conditional compilation of code for the platform without the need
> for additional compiler flags. It shouldn't exist on non Apple platforms.
>
> - Paul
>
>> On Feb 13, 2024, at 8:21 AM, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de>
>> wrote:
>>
>> Hi Paul,
>>
>> thanks. I have incorporated your diffs, SVN 1752.
>> Please check on your Apple since I don't own one (⎕FIO ¯16
>> to provoke a stack dump).
>>
>> I was also wondering where macro _APPLE_ is defined. In a header file
>> (which ?) or with -D on the command line? In the latter case we could let
>> ./configure set the macro (for that I would need to know the output of
>> the uname command on your machine).
>>
>> Best Regards,
>> Jürgen
>>
>>
>> On 2/12/24 23:40, Paul Rockwell wrote:
>>> I've found that stack traces don't display correctly with GNU APL on macOS
>>> platforms (Intel and Apple Silicon). Examining the source for Backtrace.cc,
>>> I've found that function Backtrace::show_item() is expecting the string
>>> passed to it to look like this:
>>>
>>> // ./apl(_ZN10APL_parser9nextTokenEv+0x1dc) [0x80778dc]
>>> // │││││ │││││ │││││││││
>>> // └┴┴┴┴─── program name │││││ └┴┴┴┴┴┴┴┴───── abs_addr
>>> // └┴┴┴┴───────────────── asm_offset
>>>
>>> The macOS system function backtrace_symbols() - called by Backtrace::show()
>>> returns the strings in this format:
>>>
>>> //
>>> // 14 apl 0x00000001000a93f0
>>> _ZN9Workspace19immediate_executionEb + 68
>>> // ││ └┴┴─── program name ││││││││││││││││││
>>> ││││││││││││││││││|||||||||||||||||| └┴─── asm_offset
>>> // └┴─── stack level ││││││││││││││││││
>>> └┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴─── function name
>>> // └┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴─────
>>> abs_addr
>>> //
>>>
>>> These strings don't match what the code is looking for, so the stack trace
>>> doesn't contain any useful information.
>>>
>>> I prototyped some changes to Backtrace::show_item() to be able to recognize
>>> that GNU APL is being built on Apple macOS, and parse the macOS
>>> backtrace_symbols() string format. The resulting code seems to compile and
>>> work correctly on Intel Linux and macOS (both on Intel and Apple Silicon
>>> CPUs).
>>>
>>> I've attached the diffs between SVN 1745 and my changed code. (I also made
>>> some other changes to the code to reflect use of nullptr and '\0' instead
>>> of the number 0 to improve the contextual clarity of some of the code.
>>> There are also a couple of changes to remove some compiler warnings on
>>> macOS for unreachable code)
>>>
>>> You're welcome to use them if you find them useful.
>>>
>>> - Paul Rockwell
>>>
>>>
>>
