From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#66575: [PATCH] Gud lldb support Date: Tue, 17 Oct 2023 14:30:41 +0200 Message-ID: References: <7A4E9221-C0A4-4A98-A80A-5FD58C95C014@gmail.com> <19FFB7CA-6501-4E62-9EC6-D5F2DB680D70@gmail.com> <76E471C3-4926-4B71-B945-0C87BB04B0CD@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32170"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66575@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 17 14:31:56 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qsjEp-00088m-VL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Oct 2023 14:31:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qsjEZ-0005N3-7P; Tue, 17 Oct 2023 08:31:39 -0400 Original-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 1qsjEX-0005DJ-Kf for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 08:31:37 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qsjEW-0005Zy-Kz for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 08:31:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qsjEv-0004Az-Vx for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 08:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Oct 2023 12:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66575 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66575-submit@debbugs.gnu.org id=B66575.169754587916000 (code B ref 66575); Tue, 17 Oct 2023 12:32:01 +0000 Original-Received: (at 66575) by debbugs.gnu.org; 17 Oct 2023 12:31:19 +0000 Original-Received: from localhost ([127.0.0.1]:58792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsjEF-0004A0-2L for submit@debbugs.gnu.org; Tue, 17 Oct 2023 08:31:19 -0400 Original-Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:49337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsjEB-00049k-Nx for 66575@debbugs.gnu.org; Tue, 17 Oct 2023 08:31:18 -0400 Original-Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-53e70b0a218so4996432a12.2 for <66575@debbugs.gnu.org>; Tue, 17 Oct 2023 05:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697545844; x=1698150644; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=cLXahRWAb3P87h2b5/AmbzAXGHnR0fNC2ik0naK40sE=; b=jVSDZk8vTt1B9zJM8/9vCIGB6/qexeeiqppHQr6DkEFu90fqA2XHEL1OUiXNhUS+HW zvpvPCFhCpPCtJrBpY2qithAM5mwATPV+v5SCKyYYSxDwLCla4yjM8p5kEydRGeVvlAA pf/7YrzVVum5SLCRXctzeddG0B/FTde4nFOSskB9MC9Ttg7mvOROEmjclBfq0vKmhtsc 1vk6wrJrvIY5pDrlxURGiFtmFRFNs9MKlCSLaC9mIr68Q33lxDXxoLAWpCimJsJtTOoL eHfuSKYrOLFRf1BOJcsc80dRaZdYIeDOj1hzqkE2RkwEtnnytZd37QLBrHph81aVXs3V OBTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697545844; x=1698150644; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=cLXahRWAb3P87h2b5/AmbzAXGHnR0fNC2ik0naK40sE=; b=sjtnUxONUDQLokpgIyro0TR+s0iZ175P2Q6fgdX07rFRcL0MfeCsgS+dVCzfwgF5Pm omyKN/F86ymecmzp2X3JAWHMr47eVnMImLTCJg0dCUWh3akNRDwT+hY74M81qu24nENy uxf9zJy4aiGVOe2mDm/tdmxKc2CAbHbDtaB2i4Tl4xiLyPaquujGf3DKhUaf47Iejs+L FaOX7Xk/uUzLu52W4w8x7LTZWMxcMjmPCODBSAqZXmgWj8Vk+A0gU/rJ2Vka5EiOCov1 Sh2rylLTy5KqNm0LEkMvWxfU1KIt27VATj7xMuTsfFIeNT07pkBy3j3GSZEqeLxNLDmf siXQ== X-Gm-Message-State: AOJu0Yy+Yu2BDkGGMxg2EH4Eo6L0xSpcqEUMNcCa2Jzi0p6buuxmngQC XeyAr3IZPR5zizGGpqneXOA48Wqwqhk= X-Google-Smtp-Source: AGHT+IFSyHjCOqHH/AK3uub6PA2Dw7v4qFdYMwdlJ6ezZRnqZUfWsAWAB6ESRp86wris/6DU+InhPQ== X-Received: by 2002:a50:8719:0:b0:533:9df5:ede with SMTP id i25-20020a508719000000b005339df50edemr1676846edb.14.1697545843873; Tue, 17 Oct 2023 05:30:43 -0700 (PDT) Original-Received: from Pro.fritz.box (p4fe3a123.dip0.t-ipconnect.de. [79.227.161.35]) by smtp.gmail.com with ESMTPSA id m23-20020aa7d357000000b0052348d74865sm1114212edr.61.2023.10.17.05.30.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 05:30:43 -0700 (PDT) In-Reply-To: <76E471C3-4926-4B71-B945-0C87BB04B0CD@gmail.com> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Tue, 17 Oct 2023 13:21:41 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272606 Archived-At: Mattias Engdeg=C3=A5rd writes: > 17 okt. 2023 kl. 12.03 skrev Gerd M=C3=B6llmann : > >> Hm. I'd rather see someone run lldb on Windows, and tell us if it even >> prints absolute file names. It doesn't seem to do that on macOS. > > So it seems. Odd. All right, let's use the simple pattern for now. > But doesn't this severely limit the ability of Emacs to locate the source= file? > Surely there must be a way to retrieve the directory? There is this: https://lldb.llvm.org/use/formatting.html TLDR is that one can customize what LLDB prints in certain situations. The default is, AFAIU, and I'm not an LLDB expert at all, relative paths. >> I've thought about doing that as an initialization, but then it would >> have to be manually undone once lldb is running, since .lldbinit is >> loaded first, AFAIK, if enabled (default =3D no), which one could >> suppress and load it later, but that might also not be what the user >> wants. And so on... > > Would you please explain this slowly to someone who's even less alert. > than usual this morning? Sorry :-) > I got as far as understanding that the commands turn off the emission > of source lines around the stopping position. Correct. > Fine, and this is in > general what we want if the source position is shown in an Emacs > window. At least that's what I find prettier, so I added my (our) personal preferences to src/.lldbinit :-). I didn't want to forsee what users want, that's all. In general, I find it always surprising what scenarios users come up with, and I dont't want to get into anyone's way. You get from LLDB what you configure for LLDB. > But the user may have fine reasons for wanting to run lldb > outside Emacs from time to time, and would then probably prefer the > source lines in that case. Could be, yes. In that case they could use different init files, or different LLDB config files, or write some Python (INSIDE_EMACS should be in the environment when in Emacs), or... > (Besides, I often don't see the position being tracked in a source > buffer with your patch. Is this a matter of missing directory in the > stop text?) Can you give me an example that I can try to reproduce? LLDB version and output in these cases would be also be interesting. I'm using 17.0.2 here on macOS 14.0. > And here's a completely unrelated problem: the lldb command-line > provides tab-completion on which I rely a lot as the command set is > vast and my knowledge of it is spotty. You're describing my situation :-). > Could it be provided in Emacs? Possibly. Indeed, I've started looking at this, see etc/emacs_lldb.py, function xcomplete, but I'm not there yet, because I don't fully understand what the Python API used there guarantees to return, and the documentation is silent, as usual. (Although it did get better in many areas recently, I have to admit.) So, I'm either left with guessing, or looking at the C++ sources. Anyway--chances are that I either find out, or pretend to have found out at some point :-). That would then come after the current stuff is committed, of course.