❌ About FreshRSS

Normal view

There are new articles available, click to refresh the page.
Before yesterdayNews from the Ada programming language world

gdb on MacOS Ventura fails with python library not loaded

I have a build of gdb for an Ada toolchain, and it appears there is a reference to a Python dynamic library that does not exist on my system (Intel Mac, Ventura 13.4.1 (c)).

$ which gdb
/opt/gcc-13.1.0/bin/gdb

$ gdb
dyld[19305]: Library not loaded: /Library/Frameworks/Python.framework/Versions/3.9/Python
  Referenced from: <3FCB836C-8BBC-39C7-894C-6F9582FEAE7F> /opt/gcc-13.1.0/bin/gdb
  Reason: tried: '/Library/Frameworks/Python.framework/Versions/3.9/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/Python.framework/Versions/3.9/Python' (no such file), '/Library/Frameworks/Python.framework/Versions/3.9/Python' (no such file), '/System/Library/Frameworks/Python.framework/Versions/3.9/Python' (no such file, not in dyld cache)
Abort trap: 6

$ dyld_info /opt/gcc-13.1.0/bin/gdb
/opt/gcc-13.1.0/bin/gdb [x86_64]:
    -platform:
        platform     minOS      sdk
           macOS     12.0      10.17  
    -segments:
        load-offset   segment section        sect-size  seg-size perm
        0x00000000    __TEXT                              7728KB r.x
        0x00001090             __text           5025114
        0x004CBDF0             __text_startup    23672
        0x004D1A68             __text_cold      125143
        0x004F0340             __stubs            9060
        0x004F26A4             __stub_helper      6276
        0x004F3F28             __cstring        899918
        0x005CFA80             __const          155833
        0x005F5B40             __info_plist        466
        0x005F5D18             __eh_frame       1663704
        0x0078C000    __DATA_CONST                        1088KB rw.
        0x0078C000             __got              5824
        0x0078D6C0             __mod_init_func     800
        0x0078D9E0             __const          1099176
        0x0089C000    __DATA                               304KB rw.
        0x0089C000             __la_symbol_ptr   12080
        0x0089EF30             __gcc_except_tab 118952
        0x008BBFE0             __data            76000
        0x008CE8C0             __bss             91000
        0x008E4C40             __common           9104
    -dependents:
        attributes     load path
                       /usr/lib/libiconv.2.dylib
                       /usr/lib/libncurses.5.4.dylib
                       /Library/Frameworks/Python.framework/Versions/3.9/Python
                       /usr/lib/libexpat.1.dylib
                       /opt/gcc-13.1.0/lib/libmpfr.6.dylib
                       /opt/gcc-13.1.0/lib/libgmp.10.dylib
                       /opt/gcc-13.1.0/lib/libstdc++.6.dylib
                       /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
                       /usr/lib/libSystem.B.dylib

$ ls /Library/Frameworks/Python.framework
ls: /Library/Frameworks/Python.framework: No such file or directory

$ which python3
/usr/bin/python3

$ which python3.9
/usr/local/bin/python3.9

I have installed Python via brew. Where should I look for the required library (so I can set DYLD_LIBRARY_PATH), or how can I install the proper one?

Segmentation fault in Ada inline assembler [duplicate]

I'm taking my first steps in Ada and attempting to write a package which manipulates the CPUID instruction. I found some sequences on the OSDev wiki here for checking the EFLAGS.ID bit that I'm attempting to modify into an Ada function using inline assembler, but I'm running into a persistent segfault when trying to run it. First, the package spec & body:

-- Specification file: Cpuid.ads --

with Standard_Types; use Standard_Types;

package Cpuid is
    
    function Is_Supported return Boolean;

end Cpuid;

-- Body file: Cpuid.adb --

with System.Machine_Code; use System.Machine_Code;

package body Cpuid is

    function Is_Supported return Boolean is
        HT  : constant Character := Character'Val(16#09#);
        LF  : constant Character := Character'Val(16#0A#);
        EAX : Unsigned_32 := 16#0000_0000#;
    begin
        Asm ("pushfq"                    & LF & HT &
             "pushfq"                    & LF & HT &
             "popq    %%rax"             & LF & HT &
             "xorq    0x00200000, %%rax" & LF & HT &
             "pushq   %%rax"             & LF & HT &
             "popfq"                     & LF & HT &
             "pushfq"                    & LF & HT &
             "popq    %%rax"             & LF & HT &
             "xorq    (%%rsp), %%rax"    & LF & HT &
             "popfq"                     & LF & HT &
             "andq    0x00200000, %%rax" & LF & HT &
             "movl    %%eax, %0",
             Outputs  => Unsigned_32'Asm_Output ("=g", EAX),
             Volatile => True);
        if EAX /= 16#0000_0000# then 
            return True; 
        else 
            return False; 
        end if;
    end Is_Supported;

end Cpuid;

The Cpuid.Is_Supported function is called by a main program which looks like this:

with Ada.Text_IO;    use Ada.Text_IO;
with Standard_Types; use Standard_Types;
with Cpuid;

procedure Cpuid_Check is
    Some_Int : Unsigned_32 := 0;
begin
    if Cpuid.Is_Supported then
        Put_Line ("CPUID instruction supported on this CPU.");
    else
        Put_Line ("CPUID instruction not supported.");
    end if;
end Cpuid_Check;

Note that the Standard_Types import is just a spec-only package consisting of handwritten type definitions for Unsigned_8, Unsigned_16, and Unsigned_32.

When I attempt to run this program, the program fails with PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION. Using GDB allows me to trace the error to a SIGSEGV, but I am not able to trace the violation further to a particular instruction issuance. The full debugger output is as follows:

Temporary breakpoint 14, 0x00000000004016e0 in cpuid_check ()
[program stopped: breakpoint-hit]
(gdb) -exec-next
Single stepping until exit from function _ada_cpuid_check,
which has no line number information.
[program running]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000401ede in cpuid.is_supported ()
[program stopped: signal-received]
(gdb) -exec-next
Single stepping until exit from function cpuid__is_supported,
which has no line number information.
[program running]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffc4d3473f9 in KERNEL32!IsBadReadPtr () from C:\Windows\System32\kernel32.dll
[program stopped: signal-received]
(gdb) 

I've checked to ensure that I'm leaving the stack "as I found it", which, to the best of my ability, appears to be the case - the same number of pushes and pops occur within the inline assembly section. I've also rearranged the assembly sequence into src, dest format, as my reading on GAS indicates that is the syntax used. In the process, however, I bamboozled myself - I'm more used to Intel/NASM syntax, and GAS looks like a mess in comparison.

Is there a way to rectify this function so that it functions properly?

EDIT: Here is the disassembly dump from GDB, as noted in the comments:

(gdb) disas
Dump of assembler code for function cpuid__is_supported:
   0x0000000000401ec4 <+0>: push   %rbp
   0x0000000000401ec5 <+1>: mov    %rsp,%rbp
   0x0000000000401ec8 <+4>: sub    $0x10,%rsp
   0x0000000000401ecc <+8>: movb   $0x9,-0x1(%rbp)
   0x0000000000401ed0 <+12>:    movb   $0xa,-0x2(%rbp)
   0x0000000000401ed4 <+16>:    movl   $0x0,-0x8(%rbp)
   0x0000000000401edb <+23>:    pushfq 
   0x0000000000401edc <+24>:    pushfq 
   0x0000000000401edd <+25>:    pop    %rax
=> 0x0000000000401ede <+26>:    xor    0x200000,%rax
   0x0000000000401ee6 <+34>:    push   %rax
   0x0000000000401ee7 <+35>:    popfq  
   0x0000000000401ee8 <+36>:    pushfq 
   0x0000000000401ee9 <+37>:    pop    %rax
   0x0000000000401eea <+38>:    xor    (%rsp),%rax
   0x0000000000401eee <+42>:    popfq  
   0x0000000000401eef <+43>:    and    0x200000,%rax
   0x0000000000401ef7 <+51>:    mov    %eax,%eax
   0x0000000000401ef9 <+53>:    mov    %eax,-0x8(%rbp)
   0x0000000000401efc <+56>:    cmpl   $0x0,-0x8(%rbp)
   0x0000000000401f00 <+60>:    je     0x401f09 <cpuid__is_supported+69>
   0x0000000000401f02 <+62>:    mov    $0x1,%eax
   0x0000000000401f07 <+67>:    jmp    0x401f0e <cpuid__is_supported+74>
   0x0000000000401f09 <+69>:    mov    $0x0,%eax
   0x0000000000401f0e <+74>:    nop
   0x0000000000401f0f <+75>:    nop
   0x0000000000401f10 <+76>:    add    $0x10,%rsp
   0x0000000000401f14 <+80>:    pop    %rbp
   0x0000000000401f15 <+81>:    retq   
   0x0000000000401f16 <+82>:    nop
   0x0000000000401f17 <+83>:    nop
   0x0000000000401f18 <+84>:    nop
   0x0000000000401f19 <+85>:    nop
   0x0000000000401f1a <+86>:    nop
   0x0000000000401f1b <+87>:    nop
   0x0000000000401f1c <+88>:    nop
   0x0000000000401f1d <+89>:    nop
   0x0000000000401f1e <+90>:    nop
   0x0000000000401f1f <+91>:    nop
End of assembler dump.

How can i write an unambiguous expression of overloaded functions with different return types?

I'm trying to set a breakpoint with a condition. Lets say the condition is

condition 1 temp() > 0.0

but there are functions

int temp()

and

float temp()

in the same package. gdb then asks which function is intended (multiple matches). not just once, when the condition is defined, but every time the condition is evaluated. Is it possible to define the function unambiguously, for instance by specifying file and line?

I tried adding the return type the way it was specified in the alternative gdb produced, similar to "temp return int" but that led to an error.

Mojave vs. GDB

Apple's software development tools are based on LLVM, and Apple don't seem to feel it necessary to keep GCC and friends up to date with changes in the Apple tools or security policies.

GDB has been particularly affected by this. You can see why a tool which is capable of interacting with running programs would have to be treated with caution.

Read more Β»

Arduino Due/Segger J-Link EDU

I’ve been porting my Cortex-based RTS to Arduino Due, using the J-Link JTAG interface (because who can make an RTS without a debugger?). I’ve probably forgotten my initial problems with ST-LINK (an equivalent interface included for free on the STM32F4 board, supported by OSS software), but it seemed a much less trying experience than with Segger.

There are two things with J-Link GDB Server: first, it seems like a bad idea to keep the server alive after a GDB session ends, so start it with -singlerun; and second, you absolutely must issue monitor reset before running your program. If you don’t you’ll end up like I did, scratching my head for three days trying to understand why I was getting a HardFault at the SVC that FreeRTOS uses to kick tasking off.

❌
❌