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.133.124]) by sourceware.org (Postfix) with ESMTPS id A25C23818FCE for ; Tue, 10 Jan 2023 15:28:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A25C23818FCE 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=1673364530; 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=JXRXAtg1/rbR0MkYlG1IVmOZWdwXn5k6SZ0A+/cGgDk=; b=Z7f0M4VNYyf7ZhOqvD1MkJPQnfkvd0NmCZ+zwDNCNV8LfZqKSuowo1+RXeHCpOC0R+ejAu G2imGAesubLuYGmFBUM7uFeT35o4N7Epgv0KsLs9idysBzeDn7nUrK2MKVQ/g5OuAAcCcD ANOzPxm7LHLbQmwBKhKOPOtnx1SB1tQ= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-380-DqVSNHWyOM-0QyXaHTgscg-1; Tue, 10 Jan 2023 10:28:49 -0500 X-MC-Unique: DqVSNHWyOM-0QyXaHTgscg-1 Received: by mail-vs1-f70.google.com with SMTP id j5-20020a67ef05000000b003cefdc1cbb7so2117515vsr.20 for ; Tue, 10 Jan 2023 07:28:49 -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=JXRXAtg1/rbR0MkYlG1IVmOZWdwXn5k6SZ0A+/cGgDk=; b=VmBPPhWsHW8+TjsVqHbE3iFLD6uhzBBvAyvU19/sS2qehCxcun6TnLzfGvDz67dALd eXNabhLQMVpRUc5etEbtSni7zU4euAVxVLl7LAA/zW4MmwoEttrxLG728RPBm2szVas6 0Bq/ARhph92oWYTqgUy/jbzovEgWYaccjLPIhn4cygnvST6fMMaeftpxo2ime3IhGPr5 1tFQJgm+0sNzOZQ9igJKkRbgkREwbi6pPYTQ2fyvCwp4PDnefG04uEWAAqU3oGvAnGCZ QHKM33E+NrytVTuI4E1Ri65xXpKn39L1fIGAxcMgel1s4UVLh+waEN2m9QWH98VEB8hv QtJQ== X-Gm-Message-State: AFqh2kqyw3YhPxbal+pdFdBJElmhLoM9bgVoEX3cFe1Et4+03PKTJ80L /msfFdJL4aqX8T8yT7XErTnaLUFKHkjV5o8XeyuCfLdYPekYgrZs+qvrs1i5iiQ+Zb7vPgwZMK1 9Qdhq1qL6cS1BoKYLymNZplikFKGh47Zj9w== X-Received: by 2002:a9f:2f12:0:b0:419:d688:24b2 with SMTP id x18-20020a9f2f12000000b00419d68824b2mr7847588uaj.79.1673364528359; Tue, 10 Jan 2023 07:28:48 -0800 (PST) X-Google-Smtp-Source: AMrXdXvTUnRIrdm1Ewvz7BOrOemQTsV7hlTJW03886sXu+H80Dfyn+A4aO9Tfvk8Q52HeqkYJlE8OxU5Hf5UiOGXyW0= X-Received: by 2002:a9f:2f12:0:b0:419:d688:24b2 with SMTP id x18-20020a9f2f12000000b00419d68824b2mr7847582uaj.79.1673364528061; Tue, 10 Jan 2023 07:28:48 -0800 (PST) MIME-Version: 1.0 References: <20221219135303.116222-1-mpapini@redhat.com> <3d553ffd-b848-12aa-44a8-a70a80664fcb@redhat.com> In-Reply-To: <3d553ffd-b848-12aa-44a8-a70a80664fcb@redhat.com> From: Maurizio Papini Date: Tue, 10 Jan 2023 16:28:37 +0100 Message-ID: Subject: Re: [PATCH 0/2] addr2line: new option -n to add a newline at the end To: Nick Clifton Cc: binutils@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: Hi Nick and thanks for your time. > I am sorry - I totally missed this patch submission. :-( The patch is definitely not urgent, trivial stuff indeed, and my submission day was so close to the end of 2022. > I am not sure what you are getting at here. Are you saying that addr2line > can get stuck and so a timeout is needed in order to be to distinguish between > addr2line being slow and addr2line being stuck ? If so then this sounds > like a more serious problem that needs to be addressed by something other > than just adding a blank line to the output. No, I didn't see this kind of problem. I'm talking about this use case: addr2line as a process, with "-i" option, that is reading from stdin working on a big binary, say like the Linux kernel with debug info (~400M+), so that spawning the process once is definitely better than doing it every time. > I have to say that I am kind of with Jan on this one - it seems like > a lot of effort to fix a small problem. Isn't there an easier way > that would not involve patching addr2line ? For example if you use > the -a/--addresses option then each decoded address will be prefixed > with a line containing a simple hex number. This would allow a consumer > of addr2line's output to detect the start of each decoded address. I'm thinking about using your suggestion (thanks): with -a the address is added as a prefix as you said, while it would have been useful to have it at the end :-), but querying two times... Maurizio Maurizio On Tue, Jan 10, 2023 at 1:19 PM Nick Clifton wrote: > > Hi Maurizio, > > > Do you think this should go through an RFC? Do you have any thoughts? > > I am sorry - I totally missed this patch submission. :-( > > >> This series adds a new option to addr2line (-n) to append a newline > >> after the last informative one. > > I have to say that I am kind of with Jan on this one - it seems like > a lot of effort to fix a small problem. Isn't there an easier way > that would not involve patching addr2line ? For example if you use > the -a/--addresses option then each decoded address will be prefixed > with a line containing a simple hex number. This would allow a consumer > of addr2line's output to detect the start of each decoded address. > > > > 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. > > I am not sure what you are getting at here. Are you saying that addr2line > can get stuck and so a timeout is needed in order to be to distinguish between > addr2line being slow and addr2line being stuck ? If so then this sounds > like a more serious problem that needs to be addressed by something other > than just adding a blank line to the output. > > Cheers > Nick > >