From unknown Sat Sep 06 06:36:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79360 <79360@debbugs.gnu.org> To: bug#79360 <79360@debbugs.gnu.org> Subject: Status: 30.2; lldb shows incorrect code location when no column number is available Reply-To: bug#79360 <79360@debbugs.gnu.org> Date: Sat, 06 Sep 2025 13:36:02 +0000 retitle 79360 30.2; lldb shows incorrect code location when no column numbe= r is available reassign 79360 emacs submitter 79360 Gustav H=C3=A5llberg severity 79360 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 01 10:43:14 2025 Received: (at submit) by debbugs.gnu.org; 1 Sep 2025 14:43:14 +0000 Received: from localhost ([127.0.0.1]:58100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ut5kY-0001AV-42 for submit@debbugs.gnu.org; Mon, 01 Sep 2025 10:43:14 -0400 Received: from lists.gnu.org ([2001:470:142::17]:44336) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ut5kV-00019k-VY for submit@debbugs.gnu.org; Mon, 01 Sep 2025 10:43:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ut5kF-0006TE-K6 for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2025 10:42:56 -0400 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ut5kA-0006vo-Vr for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2025 10:42:53 -0400 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-61e8fe26614so2417294a12.1 for ; Mon, 01 Sep 2025 07:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756737765; x=1757342565; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5r9HEh+0ld8CIZsmTxppHGRrI79waYAutgNlpMix1Pg=; b=XfwGQ/U6RxPRpzTLnItZs16GB5QwmfAGv8NjlYjGW0iXJzXLUum5qLcguelLiaFYG0 SXfg2qObCO9J70+KGgjIu+xnAoe8GFQekwb6+fUGBCAIqJe79b7FesTIEtREgagt6r71 BBuRJgOC2ao9L+GdxmwpWcvjnBwMriiHZ896vhL9nnSwLX4pbMCL7MzsD1l6NCbGjIqA zNMbKzPI8WNiCjBXCS7dfA548tnHcFl0Lyq06NJXf/W5/FDhkUxz9B+flZdZ7BCtq4cp HQuRE0GbU1/iruFIYdehjvamFLHfdKe/LJ2S/SDmyIL72anTXcIKAUke7ykD+OssT6J4 IGfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756737765; x=1757342565; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5r9HEh+0ld8CIZsmTxppHGRrI79waYAutgNlpMix1Pg=; b=q9nKygl3U0E4NrNgdadKksp5TT/QkwYxYoDDGHyxEB03qSiTrVRJfqMK1bHfvb7uxx BODfEbix0A6QRsMRh3dE1UWHb3d3HrTbzxPKIRkLxODYJshMIiBFV4q48SkkRz46VEz3 SHepy7g0Bu99uGqV7MQSbCTTfTyo5We/Ot5OXS10lqFgRkSkFyVi3gddco7EMPdaFve2 +zf0Z4FTwVcUdwBCw8OYs2U6ozseiozY7FA9q25Niq1YWtMaJJCCCT8EqgT91ZMjWlDo UWglXKO9VxblsG93Jchhzz3/zOoCy+7lhzc/WsG0EZw2NtobJnyp0QGEQLTzcG6zpvnq P6XA== X-Gm-Message-State: AOJu0Yy+iSWppPWcxnqe3yzXOeka3tF9RjANGVmm/h8JW8OjSAARSPxh ehV8fG162PvbdDMiNaSd61/KVynftn91cT2JRWXwlRsxeafAXEnmnFmI8d+votzCJH18mfi87jS /pJgiW23M6lLkAQMhnZuwVXAYkTP/1Z8CyLCV X-Gm-Gg: ASbGncva4llieDqebT9I+CPInDEuzO/uvQmh7xCTeWzVL7pqwavpv0zc+Z5y7R7PHn0 j7xwosO2c85ioltf/Okpi/ol12hwuu5xQhSom7haBlGKgz5p3MVO9pubYFbG8I/gyBwJivqp69p g6lvSSBf0hD9w3iHr72vm0bx0EDXCib1Xh7t7uZse6MAqJm2GtGMAMF26zcWhI29P9AnutQrZ4Z 15AzlqaB63VQm5e X-Google-Smtp-Source: AGHT+IGWqBK8iqNOHEFZnWKrJdc6f/rOUVg3e2jv3oFJvcS2FzCd3+DlYK0x9yUjEMF6+9X8pJToomXxKQQpuDfhmR0= X-Received: by 2002:a05:6402:1d4b:b0:61c:8d7a:9162 with SMTP id 4fb4d7f45d1cf-61d26861b51mr6284536a12.1.1756737765015; Mon, 01 Sep 2025 07:42:45 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Gustav_H=C3=A5llberg?= Date: Mon, 1 Sep 2025 16:42:33 +0200 X-Gm-Features: Ac12FXy3TcpcGWU0d6yFqyuXLxnnjpd2HtkAb8SYkFrh-2Xf-welTqU88ClM9aM Message-ID: Subject: 30.2; lldb shows incorrect code location when no column number is available To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="00000000000072bc80063dbe6284" Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=gustav@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000072bc80063dbe6284 Content-Type: multipart/alternative; boundary="00000000000072bc7e063dbe6282" --00000000000072bc7e063dbe6282 Content-Type: text/plain; charset="UTF-8" In (lldb), there is a bug that positions the source code location on the last character of the previous line if lldb doesn't report a column number. Example, save the following as "t.s" and compile (on x86-64) with "gcc -g t.s -o t": .global _main _main: xor %eax,%eax ret and debug using (lldb "lldb ./t"): (lldb) *b main* : (lldb) *run* : (lldb) *disas*t`main: 0x555555555129 <+0>: xorl %eax, %eax -> 0x55555555512b <+2>: retq but the source code location ends up at the last character of the "xor %eax..." line. Attaching proposed pach against 66ef930ebea4618c1dac71a09495766476ced1d6. --00000000000072bc7e063dbe6282 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In (lldb), there is a bug that positions the source code l= ocation on the last character of the previous line if lldb doesn't repo= rt a column number.

Example, save the following as "t.s&qu= ot; and compile (on x86-64) with "gcc -g t.s -o t":
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .global _m= ain
_main:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xor %eax,%eax
=C2=A0 =C2=A0= =C2=A0 =C2=A0 ret

and debug using (lldb "lld= b ./t"):

(lldb) b= main
=C2=A0 :
(lldb) r= un
=C2=A0 :
(lldb) disa= s
t`main:
=C2=A0 =C2=A0 0x555555555129 <+0>: xorl =C2=A0 %e= ax, %eax
-> =C2=A00x55555555512b <+2>: retq

but the source code location ends up at the last character= of the "xor %eax..." line.

Attaching proposed pach= against=C2=A066ef930ebea4618c1dac71a09495766476ced1d6.

--00000000000072bc7e063dbe6282-- --00000000000072bc80063dbe6284 Content-Type: application/octet-stream; name="0001-lldb-bugfix-source-code-location-without-column.patch" Content-Disposition: attachment; filename="0001-lldb-bugfix-source-code-location-without-column.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf185jb30 RnJvbSA3YzhiOThkNDQ4YWEwNzk4ZmI5NDE2ZjBhN2ViODMzOGJkNzc1NjNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/R3VzdGF2PTIwSD1DMz1BNWxsYmVyZz89IDxl bWFjc0Bhc2tndXN0YXYuY29tPgpEYXRlOiBNb24sIDEgU2VwIDIwMjUgMTI6MzE6NDkgKzAyMDAK U3ViamVjdDogW1BBVENIXSBsbGRiOiBidWdmaXggc291cmNlIGNvZGUgbG9jYXRpb24gd2l0aG91 dCBjb2x1bW4KCiogbGlzcC9wcm9nbW9kZXMvZ3VkLmVsIChndWQtbGxkYi1tYXJrZXItZmlsdGVy KTogRml4IHByb2JsZW0Kd2hlcmUgdGhlIHNvdXJjZSBjb2RlIGxvY2F0aW9uIGVuZHMgdXAgYXQg dGhlIGxhc3QgY2hhcmFjdGVyIG9mCnRoZSBwcmV2aW91cyBsaW5lIGlmIG5vIChvciB6ZXJvKSBj b2x1bW4gaXMgcmVwb3J0ZWQgYnkgbGxkYi4KLS0tCiBsaXNwL3Byb2dtb2Rlcy9ndWQuZWwgfCAx MSArKysrKysrLS0tLQogMSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL3Byb2dtb2Rlcy9ndWQuZWwgYi9saXNwL3Byb2dtb2Rl cy9ndWQuZWwKaW5kZXggNzEwODY3M2QuLjU5ODBiYzJmIDEwMDY0NAotLS0gYS9saXNwL3Byb2dt b2Rlcy9ndWQuZWwKKysrIGIvbGlzcC9wcm9nbW9kZXMvZ3VkLmVsCkBAIC00NDYsOCArNDQ2LDkg QEAgZ3VkLWRlZgogICAgICAsKGlmIGtleSBgKGRlZmluZS1rZXkgZ3VkLWdsb2JhbC1tYXAgLGtl eSAjJyxmdW5jKSkpKQogCiA7OyBXaGVyZSBndWQtZGlzcGxheS1mcmFtZSBzaG91bGQgcHV0IHRo ZSBkZWJ1Z2dpbmcgYXJyb3c7IGEgY29ucyBvZgotOzsgKGZpbGVuYW1lIC4gbGluZS1udW1iZXIp LiAgVGhpcyBpcyBzZXQgYnkgdGhlIG1hcmtlci1maWx0ZXIsIHdoaWNoIHNjYW5zCi07OyB0aGUg ZGVidWdnZXIncyBvdXRwdXQgZm9yIGluZGljYXRpb25zIG9mIHRoZSBjdXJyZW50IHByb2dyYW0g Y291bnRlci4KKzs7IChmaWxlbmFtZSAuIGxpbmUtbnVtYmVyKSBvciAobGlzdCBmaWxlbmFtZSBs aW5lLW51bWJlciBjb2x1bW4tbnVtYmVyKS4KKzs7IFRoaXMgaXMgc2V0IGJ5IHRoZSBtYXJrZXIt ZmlsdGVyLCB3aGljaCBzY2FucyB0aGUgZGVidWdnZXIncyBvdXRwdXQKKzs7IGZvciBpbmRpY2F0 aW9ucyBvZiB0aGUgY3VycmVudCBwcm9ncmFtIGNvdW50ZXIuCiAoZGVmdmFyIGd1ZC1sYXN0LWZy YW1lIG5pbCkKIAogOzsgVXNlZCBieSBndWQtcmVmcmVzaCwgd2hpY2ggc2hvdWxkIGNhdXNlIGd1 ZC1kaXNwbGF5LWZyYW1lIHRvIHJlZGlzcGxheQpAQCAtMzg1NCw4ICszODU1LDEwIEBAIGd1ZC1s bGRiLW1hcmtlci1maWx0ZXIKICAgICAgICAgIChsYW1iZGEgKG0pCiAgICAgICAgICAgIChsZXQg KChsaW5lIChzdHJpbmctdG8tbnVtYmVyIChtYXRjaC1zdHJpbmcgMSBtKSkpCiAgICAgICAgICAg ICAgICAgIChjb2wgKHN0cmluZy10by1udW1iZXIgKG1hdGNoLXN0cmluZyAyIG0pKSkKLSAgICAg ICAgICAgICAgICAgKGZpbGUgIChtYXRjaC1zdHJpbmcgMyBtKSkpCi0gICAgICAgICAgICAgKHNl dHEgZ3VkLWxhc3QtZnJhbWUgKGxpc3QgZmlsZSBsaW5lIGNvbCkpKQorICAgICAgICAgICAgICAg ICAoZmlsZSAobWF0Y2gtc3RyaW5nIDMgbSkpKQorICAgICAgICAgICAgIChzZXRxIGd1ZC1sYXN0 LWZyYW1lIChpZiAoemVyb3AgY29sKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAoY29ucyBmaWxlIGxpbmUpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobGlzdCBmaWxlIGxpbmUgY29sKSkpKQogICAgICAgICAgICA7OyBSZW1vdmUgdGhlIGxpbmUg c28gdGhhdCB0aGUgdXNlciB3b24ndCBzZWUgaXQuCiAgICAgICAgICAgICIiKQogICAgICAgICAg c3RyaW5nIHQgdCkpCi0tIAoyLjUwLjEKCg== --00000000000072bc80063dbe6284-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 01 11:52:37 2025 Received: (at 79360) by debbugs.gnu.org; 1 Sep 2025 15:52:37 +0000 Received: from localhost ([127.0.0.1]:58265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ut6ph-0007Ae-GP for submit@debbugs.gnu.org; Mon, 01 Sep 2025 11:52:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38892) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ut6pf-0007AQ-Rs for 79360@debbugs.gnu.org; Mon, 01 Sep 2025 11:52:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ut6pa-0002I2-Hy; Mon, 01 Sep 2025 11:52:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ljgND6xvBlBj9rqahgw8gIzaEGGAtlNb1xumBZeIy6s=; b=MO3tU+ZQW/LZfkPwDbTN iBeVx+1ybZBH5XXDii52bLKb+svBBDiwHC9UhuzUAS1PFob/8HqFVN+L9cI+EoYRm7xA4DcQj82TN stTszij/SzV8SV78U5UeTQX7AVZY+NsovstZSIdPg2bH1CFLu6thHIg1Q07lPYnZO4ERp5cnG8iPN XGzJ11ffwWCn6Dj/M3VaoBaL7l6pY6BQ8J0glYFFTKVYybcjbqEOucriyCXciomtX1W5Gpyrw6YbF 2LK0LQekf6OCuqyv13K+OX/i4sPQ9XYrJ1r8C7ZaTc3eGqGhtm9qEiNHP+iGpWJovtYECWtDlkOSL llMgtZbXnhVcpw==; Date: Mon, 01 Sep 2025 18:52:26 +0300 Message-Id: <86tt1mmapx.fsf@gnu.org> From: Eli Zaretskii To: Gustav =?utf-8?Q?H=C3=A5llberg?= In-Reply-To: (message from Gustav =?utf-8?Q?H=C3=A5llberg?= on Mon, 1 Sep 2025 16:42:33 +0200) Subject: Re: bug#79360: 30.2; lldb shows incorrect code location when no column number is available References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79360 Cc: 79360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gustav Hållberg > Date: Mon, 1 Sep 2025 16:42:33 +0200 > > In (lldb), there is a bug that positions the source code location on the last character of the previous line if > lldb doesn't report a column number. > > Example, save the following as "t.s" and compile (on x86-64) with "gcc -g t.s -o t": > > .global _main > _main: > xor %eax,%eax > ret > > and debug using (lldb "lldb ./t"): > > (lldb) b main > : > (lldb) run > : > (lldb) disas > t`main: > 0x555555555129 <+0>: xorl %eax, %eax > -> 0x55555555512b <+2>: retq > > but the source code location ends up at the last character of the "xor %eax..." line. > > Attaching proposed pach against 66ef930ebea4618c1dac71a09495766476ced1d6. Thanks, but if this is a bug in lldb, why shouldn't it be solved in lldb, not in Emacs? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 01 13:09:28 2025 Received: (at 79360) by debbugs.gnu.org; 1 Sep 2025 17:09:28 +0000 Received: from localhost ([127.0.0.1]:58376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ut824-0002AJ-5Z for submit@debbugs.gnu.org; Mon, 01 Sep 2025 13:09:28 -0400 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:54729) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ut821-0002A3-Do for 79360@debbugs.gnu.org; Mon, 01 Sep 2025 13:09:26 -0400 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-61cebce2f78so8187859a12.1 for <79360@debbugs.gnu.org>; Mon, 01 Sep 2025 10:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756746559; x=1757351359; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MvqNEnYkr7jOi5w3UZl7UtCS9yZDsDpCMz7SxEgUkNQ=; b=i83dnJTVUveghrEUdrsoyqTgoO4KPLhKxOjMeN/UWKm5ab3jter9Z1KilY7u1zEqeW /JkosMOD88RkQ/0GmbPW4LmatGyNfzrtQMx5X5WBzavC7kxdhgoYJ4S3geC4aZsvx1DV yQCrsDQ/JZ64mJp+EDK4hpuItY22Exy7naBXsZegZhhSK2/HDBO2Z8ZXl4P5adye1YH1 /6YYp7qe03KpKh919XE+AURTIrZSEg8yhUynG2FdpgOqGOgevMxOYUBeppP+GEcVdYpP D6exGzdGKA4hTX1cKHf30hL3U6Ex3vLDwdtOQfYzvXABQZss1yCQVnZArAs4eUEaJSi3 NOkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756746559; x=1757351359; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MvqNEnYkr7jOi5w3UZl7UtCS9yZDsDpCMz7SxEgUkNQ=; b=v8jnvrrsoTgsH9xOtvbCLi3ck7N/ZqZ8thFX2waB3KxTEPQjH6wSrR48QudOSoSNWp odbqeBJgCPrr/zlws3h0N3F1ihvRA3LH5gVgywLySp07awdzdIznCHveaRcSCswlxGpR r7MzpsKwSTKTStsiO8uj7lYMG01G2e6rfucXDn7xM8XK/jSKTzVTZn+npeYsVLAodtWY BNg6OH9Ypoj6NHC+mwSiLBNMCWhiNKjDENq1RlADgnloE8PZ5o8gM2sBLxw9thZJqi4s FuffbGfD5CjVQSUeSsFF91kcGSVaDH8zzxVGmkSGaXCrWZPWkf55M0zwdr9njsC3o7jG 6i9g== X-Gm-Message-State: AOJu0Yz7CDNBTtY9BDnJeSrbK6E8uzBZB5A5XPW6tp3FtD3IJk49uz0z bCl6R+VoEfS1qzNjlaSG3x7fi7rP3FawT8qWMxQAb86794nC4FXbvdMz0D7CVWMtkPZb6Y985YR q5zmximP38saOJbG/udMPQtbS925IJ7VGlA== X-Gm-Gg: ASbGnctrPIG3+ttRbT25MlPxSDR/Ti1uIDUEDYCxZCBHAeWgp5XSOqJA1Zh1CSfZv9M ZGJZAX72p/JKJcowo5+tNDy6feGrJKSe259adVon+CJqW4HsuyA+Dfziq2XxWviGhyjMwlZEzjF ccPRPu96f282SyNstfDL4w2su0kMv4Py8wNn74oB0ji9Igdbqso8FDQP8y9L+Ka63kqTv1GmY78 pvat2CCNMTkmoxb X-Google-Smtp-Source: AGHT+IH10hOJAo0tXcKOeAhDiawGFtlEe/zuabBpjpbApEbiVxkLmaXB7F5jEtQim5nHQG/BP8Egtb041lG5VuxDal8= X-Received: by 2002:a05:6402:51cb:b0:61c:7902:54b1 with SMTP id 4fb4d7f45d1cf-61d26d84f68mr7237920a12.18.1756746558991; Mon, 01 Sep 2025 10:09:18 -0700 (PDT) MIME-Version: 1.0 References: <86tt1mmapx.fsf@gnu.org> In-Reply-To: <86tt1mmapx.fsf@gnu.org> From: =?UTF-8?Q?Gustav_H=C3=A5llberg?= Date: Mon, 1 Sep 2025 19:09:10 +0200 X-Gm-Features: Ac12FXwKMdn0bnhZ8hG35dVqahtM4N97gDr5eJPfzZd3pU93ar4O1Ty677U-y-4 Message-ID: Subject: Re: bug#79360: 30.2; lldb shows incorrect code location when no column number is available To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000009bf4bd063dc06e7d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79360 Cc: 79360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000009bf4bd063dc06e7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is a bug in the emacs M-x lldb command. lldb (the tool) correctly sends an empty column field when it has no column number debug information. If you look at the patch you'll see that the gud.el regexp (correctly) matches an empty digit sequence for the column number field, but that (incorrectly) is treated as column zero (which doesn't exist) rather than an absent column number field. On Mon, Sep 1, 2025 at 5:52=E2=80=AFPM Eli Zaretskii wrote: > > From: Gustav H=C3=A5llberg > > Date: Mon, 1 Sep 2025 16:42:33 +0200 > > > > In (lldb), there is a bug that positions the source code location on th= e > last character of the previous line if > > lldb doesn't report a column number. > > > > Example, save the following as "t.s" and compile (on x86-64) with "gcc > -g t.s -o t": > > > > .global _main > > _main: > > xor %eax,%eax > > ret > > > > and debug using (lldb "lldb ./t"): > > > > (lldb) b main > > : > > (lldb) run > > : > > (lldb) disas > > t`main: > > 0x555555555129 <+0>: xorl %eax, %eax > > -> 0x55555555512b <+2>: retq > > > > but the source code location ends up at the last character of the "xor > %eax..." line. > > > > Attaching proposed pach against 66ef930ebea4618c1dac71a09495766476ced1d= 6. > > Thanks, but if this is a bug in lldb, why shouldn't it be solved in > lldb, not in Emacs? > --0000000000009bf4bd063dc06e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is a bug in the emacs M-x lldb command= .

lldb (the tool) correctl= y sends an empty column field when it has no column number debug informatio= n.

If you look at the patch you'll see that the gud= .el regexp (correctly) matches an empty digit sequence for the column numbe= r field, but that (incorrectly) is treated as column zero (which doesn'= t exist) rather than an absent column number field.

On Mon, Sep 1, 2025 at 5:52=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Gustav H=C3=A5llberg <gustav@gmail.com>
> Date: Mon, 1 Sep 2025 16:42:33 +0200
>
> In (lldb), there is a bug that positions the source code location on t= he last character of the previous line if
> lldb doesn't report a column number.
>
> Example, save the following as "t.s" and compile (on x86-64)= with "gcc -g t.s -o t":
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.global _main
> _main:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xor %eax,%eax
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret
>
> and debug using (lldb "lldb ./t"):
>
> (lldb) b main
>=C2=A0 =C2=A0:
> (lldb) run
>=C2=A0 =C2=A0:
> (lldb) disas
> t`main:
>=C2=A0 =C2=A0 =C2=A00x555555555129 <+0>: xorl=C2=A0 =C2=A0%eax, %= eax
> ->=C2=A0 0x55555555512b <+2>: retq
>
> but the source code location ends up at the last character of the &quo= t;xor %eax..." line.
>
> Attaching proposed pach against 66ef930ebea4618c1dac71a09495766476ced1= d6.

Thanks, but if this is a bug in lldb, why shouldn't it be solved in
lldb, not in Emacs?
--0000000000009bf4bd063dc06e7d-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 06 05:06:32 2025 Received: (at 79360-done) by debbugs.gnu.org; 6 Sep 2025 09:06:32 +0000 Received: from localhost ([127.0.0.1]:34366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuosR-0005BB-Os for submit@debbugs.gnu.org; Sat, 06 Sep 2025 05:06:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59322) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuosM-0005Al-E3 for 79360-done@debbugs.gnu.org; Sat, 06 Sep 2025 05:06:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uuosF-000268-1O; Sat, 06 Sep 2025 05:06:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=7/SZjneWKYJYe0qgL+Uc256KVQbL+kVJTMYwaasNobo=; b=kYDHlUGJgDI8y4JGLrp5 V2/VMd+OqwKxPvjd0on08AVg1qTWQQw+/FA5RSaWdd1OGj3ZzkF1FopGhNwGOBioe314kfc4kEI5+ mk+4RgwEhbQeDDxrzVsKXTogZkEqjUXsTBhsK6xXoCsIj4pu3fbawaqLNsYophYtKF1817fIS4kPt ZuIEd4pBTFyMfKPOefdAy22+xzhsaRZnqwqzsQLgeVT79LRA2FUPZlTXi2R8MW3pXRXjJa9WAs3ZR YJZZnObPHaQ5vsELkJo+9CAO9EuMrDOwR5xkSNbVRzkozpg27gP2GHxoh4s7geBNeha61BdR4qn1v AQgbCuctgTYFQg==; Date: Sat, 06 Sep 2025 12:06:14 +0300 Message-Id: <86tt1geyrd.fsf@gnu.org> From: Eli Zaretskii To: Gustav =?utf-8?Q?H=C3=A5llberg?= In-Reply-To: (message from Gustav =?utf-8?Q?H=C3=A5llberg?= on Mon, 1 Sep 2025 19:09:10 +0200) Subject: Re: bug#79360: 30.2; lldb shows incorrect code location when no column number is available References: <86tt1mmapx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79360-done Cc: 79360-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gustav Hållberg > Date: Mon, 1 Sep 2025 19:09:10 +0200 > Cc: 79360@debbugs.gnu.org > > It is a bug in the emacs M-x lldb command. > > lldb (the tool) correctly sends an empty column field when it has no column number debug information. > > If you look at the patch you'll see that the gud.el regexp (correctly) matches an empty digit sequence for the > column number field, but that (incorrectly) is treated as column zero (which doesn't exist) rather than an > absent column number field. Thanks, I've now installed the change on the master branch, and I'm therefore closing this bug.