From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2D1BA38C2999; Fri, 7 Jun 2024 16:18:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D1BA38C2999 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1717777121; bh=ZVQOPQi/5QgBXB0DiG+BwoFHDjNQVfsCJ/UUrTN+P48=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TvaK/7IQIUZHnJedxo2Xd3/pXAbHXFD0xcVMkoQzDph+TKQEETQkNwH7dlaESI1Da cukYZt1FDHVCXxz4vzUWLtqwuthoKVGFR1ipBggBTGyZIdHqINuD/ly5EyBD5EPFBh KCkv81EHULsssd/+3OFhj5mbOJ6RLQqdFG8RXri0= From: "ciaranwoodward at xmos dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/31853] GDB's use of iconv does not work with macOS Sonoma Date: Fri, 07 Jun 2024 16:18:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ciaranwoodward at xmos dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31853 --- Comment #4 from Ciaran Woodward --- I wrote a quick preprocessor check to double-confirm: > * Does not define __STDC_ISO_10646__ > * ... and defines _LIBICONV_VERSION And both of these are correct. __STDC_ISO_10646__ is not defined, and _LIBICONV_VERSION is defined as 0x010B (with a comment which claims "compatible"). > * ... but for its own libiconv, not the GNU libiconv I can't find any official documentation stating that libiconv was replaced, but have found references to it on online forums, and the header is substantially different (but claims to be compatible). It seems it was Apple's intention to provide this iconv as a 'drop in' replacement, so building against an old "mac SDK" (so your application is compatible with older macOSs) will still have the new non-GNU libiconv linked when run on the newer system. > * ... but does use UTF-32 as its wchar_t encoding I am not sure about this, nor how to check it really. I can see the wchar_t type is 4-bytes in size, but maybe that is different for very-old versions of macOS. The intermediate_encoding() (in charset.c) function that ends up getting used as INTERMEDIATE_ENCODING will adjust the bitwidth to match the width of wchar_t. It will use either UTF-16,UTF-32,UCS-2 or UCS-4 depending on what iconv_open supports (by runtime testing). >From my understanding, this is all fine because GDB is only using this as an intermediate encoding, not expecting the host or target to necessarily understand it natively. > Also, will the approach taken in your patch also work on > older versions of the OS? I have tested on all of the 'currently supported' versions of macOS and it seems to work, but I really don't understand the platform well enough to guarantee it will work for every possible past version. I also reported this issue to Apple, but no guarantees they actually acknowledge/fix it in their iconv implementation :) --=20 You are receiving this mail because: You are on the CC list for the bug.=