From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 126403858CDA for ; Tue, 10 Jan 2023 14:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 126403858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673360254; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PRUt8r3aa6jM7ofXeWqXf3W0ScjlDgHoiS9U8DXD0LY=; b=Dt0OE9L3lZdIEHIXbQmWY4YSpY0ga/ONRSkXKDI2zZKyl8xAce1pdiAZrInfvmd7oUco15 SsqWLVVZFA0137kLGGEpG3TAqTtcRKST2GiJCP4MpA+T19PweJZp+tlCS5RLa9Y+s48MMq 8ciduufvkKScDLkYMqJsIiu5VeDgnFU= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-455-9p4vIVbjNHWm9fXNSDsZ1A-1; Tue, 10 Jan 2023 09:17:33 -0500 X-MC-Unique: 9p4vIVbjNHWm9fXNSDsZ1A-1 Received: by mail-vs1-f69.google.com with SMTP id p9-20020a056102200900b003d0a4ef871aso1562603vsr.6 for ; Tue, 10 Jan 2023 06:17:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=PRUt8r3aa6jM7ofXeWqXf3W0ScjlDgHoiS9U8DXD0LY=; b=33fOoqss2Kc+s8tvNN89/NAA2HKqZkkiil0Gg5ubm1ZElKGQde+XDEzNTGOkXwH6oD V5QZ5+cQgb1VroQws8pVQYE+hIiqWNzRYdZrl5lJO2c8fRRE50mKBvcPoyKaZPw+qId4 FatfOcmv8kYS0HT9lqh4C1HVH6SXUfTCRBjYnwIypoTyKS2LzdFsRaAt0y+67GTE0f59 CZ9G/Fp272TZ6EjWby3rHDW7Is793axkCyhfsKty10+U6xGuVT1SClS3kW5VxvwZrGjs 7aaDRAGenoKb+UcExQwgkA0SEGuDxOf3fRsBHVnUNuMNthTJsqK0Wr1lq/XpGcofiO+l BqGg== X-Gm-Message-State: AFqh2kpd7+4rqIAjQNnaRZ+ix1HlHZBYTZhb8vc3OYjX8C5qG1PlpFyJ 3dD6EPSrdMak3hA9/bZ4zTkCwRzA120Tcdxbe70xFsYwp3tOeEOA0wGSZ8nlFQFW9pAzBpf6zP6 F8vxypg1URdqj/NAnf3ovESGRmRyGLxHTng== X-Received: by 2002:a05:6102:3587:b0:3c8:13be:cfd2 with SMTP id h7-20020a056102358700b003c813becfd2mr9160767vsu.67.1673360252880; Tue, 10 Jan 2023 06:17:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXtJnfP2oVpgl4O/spf/W8k6vaw0p9I2S5sn3qiLK/7TRH//59SUZXmcKWvaelI7Vs0frhjpQEXeklpFuKb67xk= X-Received: by 2002:a05:6102:3587:b0:3c8:13be:cfd2 with SMTP id h7-20020a056102358700b003c813becfd2mr9160762vsu.67.1673360252552; Tue, 10 Jan 2023 06:17:32 -0800 (PST) MIME-Version: 1.0 References: <20221219135303.116222-1-mpapini@redhat.com> In-Reply-To: From: Maurizio Papini Date: Tue, 10 Jan 2023 15:17:21 +0100 Message-ID: Subject: Re: [PATCH 0/2] addr2line: new option -n to add a newline at the end To: Jan Beulich Cc: binutils@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000006f608305f1e98b52" X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000006f608305f1e98b52 Content-Type: text/plain; charset="UTF-8" Thanks for your feedback Jan. Yes, I understand that one option for a single newline smells fulsome but the idea is to use it to mark the end of output when addr2line is used as a "server" process: right now I see only the "-i" use case, but there could be others in the future for new options. Said that I would propose adding the "add-newline" long option only to trivially add a new line, that could be reused for other output. What do you think? Maurizio On Mon, Jan 9, 2023 at 5:17 PM Jan Beulich wrote: > On 09.01.2023 17:04, Maurizio Papini via Binutils wrote: > > Do you think this should go through an RFC? Do you have any thoughts? > > Well, I'm of two minds here, which so far kept me from responding: On one > hand an option that's useful to someone is probably a good thing. Otoh an > option to control a single newline character seems a little too fine > grained to me. Plus I'm a little concerned of burning a short option for > this (niche?) issue. Since you say it's specifically an issue with -i, > would it be an option to add a long-only option providing the intended > variant of behavior, i.e. combining what would (aiui) be "-i -n" with the > current proposal? > > Jan > > > On Mon, Dec 19, 2022 at 2:53 PM Maurizio Papini > wrote: > > > >> This series adds a new option to addr2line (-n) to append a newline > >> after the last informative one. > >> > >> This new option is helpful for using a running addr2line process and > >> performing queries, in particular when the option -i is requested: the > >> additional empty line can be used to mark the end of the inlined > functions > >> lists so that an application can get the output without defining a > timeout. > >> > >> The first patch adds the new option while the second one adds the > relative > >> test. > >> > >> Let me know what you think. > >> > >> Maurizio > >> > >> > >> Maurizio Papini (2): > >> addr2line: new option -n to add a newline at the end > >> addr2line: test to check -n option > >> > >> binutils/addr2line.c | 11 +++++++++-- > >> binutils/doc/binutils.texi | 5 +++++ > >> binutils/testsuite/binutils-all/addr2line.exp | 10 ++++++++++ > >> 3 files changed, 24 insertions(+), 2 deletions(-) > >> > >> -- > >> 2.38.1 > >> > >> > > --0000000000006f608305f1e98b52--