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 7A5263858D32 for ; Tue, 14 Nov 2023 18:46:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A5263858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7A5263858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699987581; cv=none; b=Bx52J5PFXy2geQDmNS5YVvupc41bD9pWzVRwE8A8qe4OnNx7we4gz/aeFyOBxjakf9GWBxmUFcKvH5Z1dz+fgH8hX1HSc8d7/R3kZxvmdiScjrOFfsuO2i3rRPguOjaFZ9C6Coexrlo5ZtbbPGM/2pcKur3EsgPyL8zCHKfPzJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699987581; c=relaxed/simple; bh=GR/8ykrFoVCSQKSzm1inmMCfh/wu7faShjrD7b+nmzM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=q8uzVKWGm8BnOb/pIGJ8IjMOBeOW2pYQnlhRvL51iLJro5hgRcAgwGHQ3+JGdRKCHpMsPZmhvDQeR70YT7VBJKFTCchnU3KBf0m3gslsop91cXj+OcTqcfopbTWRuLXgi4PqSGXOnINcRbO1FiTxuXGcQky15ABABS8AbwzplvI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699987580; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZCcBFJSUmUPJqR9jkQ/O2y270xKyhUFRouhiZfcBkRg=; b=irus37BnpF1ChE2GJaAJaLR1m8DPxuBlURPSPDv70tUPQWTmTWGGrSKTE3GDHoaBokqTwQ cOQAf3DE6kbQGeiuMnOHL4HKmqy2ZMob9VciJoasoTA+C97E1DiKcAhuSMZbjsmrbpLvyV UNQ4TWGO/E3zfx5XHalVAWr5ewzIK9c= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-yGmh_692PliwrdK9EATFQQ-1; Tue, 14 Nov 2023 13:46:17 -0500 X-MC-Unique: yGmh_692PliwrdK9EATFQQ-1 Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-27ffe79ec25so6005228a91.2 for ; Tue, 14 Nov 2023 10:46:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699987576; x=1700592376; h=content-transfer-encoding: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=ZCcBFJSUmUPJqR9jkQ/O2y270xKyhUFRouhiZfcBkRg=; b=iZI5mnSqsuXZkTltIiIDr03+7skrscFGk0UVzIvbd8tkXl8lx9GFHTeRD8a/5l31fQ 4JfwRF+lfeyy3JrSyozdcIUPZO+k+t31kuGEtFUauu9zFq5f9HdwfH1xiNSSLMi8mamE MvFn65DiGeozNo1KQfm9RoUWrwBqb4crYbNclQcArtty4s/ZEuLEyu9cZpRqtFPr72AH 1FPGFQdwDBPNsPRD2h4Z8VvKoRk1V154KA1RGJaMFHPfEw3l2Oks9uk0gf/Q1V8Fysz9 h/98GVEYHnbSr3VBjEvexpmPP7nbewHmfATXjnBWVSkkGlhc90AvH2q71EeyDNXxhpF+ QCWQ== X-Gm-Message-State: AOJu0YyBxRNa7OXyzJvi98M+pbK+E1F7Hq+GrPdD++MRKgvcZIxrd2OQ KsboY4z/qRQgXoLjf5HJpe2I5ZzFMcfykN7zFZ1ey/DQ3ncN2ZQ0zjH7wvK1W3PwiDrbM/EDnKQ 66iqs9ljdXYUtEubBzgqNLk6vF2399PV5FZGu2RHIno5dIZQVVUE= X-Received: by 2002:a17:90b:3506:b0:27d:306d:71c9 with SMTP id ls6-20020a17090b350600b0027d306d71c9mr6392712pjb.49.1699987576566; Tue, 14 Nov 2023 10:46:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IGhurDyQ4OWS7BlbTHEMIqbGswL5Ca9n9UX4vifTAmvIY6AqQtz7CUAsupF5aGCTZ/ROA6Copj3xeyOqx1SYBw= X-Received: by 2002:a17:90b:3506:b0:27d:306d:71c9 with SMTP id ls6-20020a17090b350600b0027d306d71c9mr6392701pjb.49.1699987576282; Tue, 14 Nov 2023 10:46:16 -0800 (PST) MIME-Version: 1.0 References: <20231112201645.25762-1-amerey@redhat.com> <5b0d1e19085a0b29a9b9ca6c14c21746dff8995a.camel@klomp.org> In-Reply-To: <5b0d1e19085a0b29a9b9ca6c14c21746dff8995a.camel@klomp.org> From: Aaron Merey Date: Tue, 14 Nov 2023 13:46:05 -0500 Message-ID: Subject: Re: [PATCH] libdwfl: Correctly handle corefile non-contiguous segments To: Mark Wielaard Cc: elfutils-devel@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 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_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Mark, On Tue, Nov 14, 2023 at 9:03=E2=80=AFAM Mark Wielaard wrot= e: > > > A couple caveats should be mentioned. First, start and end addresses > > of reported modules cannot be assumed to contain segments from only > > that module. This has always been the case however. > > There is dwfl_addrmodule/dwfl_addrsegment to find the module that > covers a specific address. Defined in libdwfl/segment.c. I think this > should handle this by checking the closes load address. But I have not > tested it. > > Normally only kernel modules (.ko ET_REL files) have multiple segments. > So it might make sense to double check none of this impacts systemtap. I'll look into this. > > Second, the testcases in this patch use a firefox corefile that is > > fairly large. The .bz2 corefile is about 47M. A clean elfutils repo > > is currently about 42M, so this corefile more than doubles the size of > > the elfutils repo. I looked for a much smaller process with > > interleaving non-contiguous shared library sections but was not able > > to find one. I've included the corefile and tests in this patch but > > they can be removed if we'd prefer to not approx. double the size of > > the repo. > > I really appreciate the testcase, but it really is too big. It is 736M > bunzip2ed (which would happen on any make check). I think this makes > the repo and the build/check a little too heavy. Also we try to include > instructions to recreate any binary test files and that isn't really > possible in this case. Agreed, this isn't a great testcase. I'm not sure if there's a way to force the linker to create segments that reproduce the bug on a much smaller process, but I'll see if I can write something by hand with libelf. Or maybe GNU poke can be of use here? I'll take a look. Aaron