From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-110.mimecast.com (us-smtp-delivery-110.mimecast.com [216.205.24.110]) by sourceware.org (Postfix) with ESMTP id EB5753858403 for ; Sat, 25 Sep 2021 07:21:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB5753858403 Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-369-85UaW1ZsNnOB9L45AXaRMg-1; Sat, 25 Sep 2021 03:21:51 -0400 X-MC-Unique: 85UaW1ZsNnOB9L45AXaRMg-1 Received: by mail-pg1-f198.google.com with SMTP id p19-20020a634f53000000b002877a03b293so16297pgl.10 for ; Sat, 25 Sep 2021 00:21:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e4/T0B7NdJV+MpAR2oXznO2dxwKinNUZm1M68LMvdTI=; b=uD8ri/egaqgB8JhfHqf585ofcYBtzlb71BxX/1HgeZ097TIMY5V+Vv84Xp91cO/2NC H/nFJR4peudJMF51OSGXYs00lhjtuZ6ASnYqiRp5/XTg5007sLv44PJ0mgU/eMSfjTJm DoxR4kU4giwrHu0v6msGbI/rImZ3n+MwxHNLfYlBANuo+EbdH18qsTjOtVyPOpMjwTUp YtFaI1BEhkLRiL1oDCqfoTsIb0e3VXS2kjqzeL+OM94MD1K/wDwaP6IraZgJgi+KFYyK 2KbXSwBlWkHlE44K8zAeIDx/sRWeIwDvoh/spvFqnfp69uNsvzCbozCcn/Qr8GIxmJZs 5C5w== X-Gm-Message-State: AOAM531bfGZeyst+bquzHeEj4nckQZucDwetHQeHSLW/nYPq/Hheva94 HSV7pjuNIs5kwKBHb/cDAqbUdYNEO8M+Q8bFscIpoZAXhgLy18dI7BqMcqKWctRO45tNdgJC01p 1zW6DLjqmEyhjH31rPMVCbXSj4oaIsTpttBTFwR/K X-Received: by 2002:aa7:9e49:0:b0:44b:2a06:715e with SMTP id z9-20020aa79e49000000b0044b2a06715emr13455499pfq.78.1632554510404; Sat, 25 Sep 2021 00:21:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGKTlc3fOAVeGQ2YKj1WLBOOM3DJzH2PiISAQGOTS7T9EKnCfc6HkHQcLdqGiZNsEgc8JCUnD8mZSesGSZLPQ= X-Received: by 2002:aa7:9e49:0:b0:44b:2a06:715e with SMTP id z9-20020aa79e49000000b0044b2a06715emr13455480pfq.78.1632554509899; Sat, 25 Sep 2021 00:21:49 -0700 (PDT) MIME-Version: 1.0 From: KJ Tsanaktsidis Date: Sat, 25 Sep 2021 17:21:39 +1000 Message-ID: Subject: dwarf_aggregate_size doesn't work with arrays in partial CUs To: elfutils-devel@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: zendesk.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 07:21:55 -0000 Hi folks, I'm writing a program that uses ptrace to poke at internal OpenSSL data structures for another process. I'm using libdw to parse the DWARF data for the copy of OpenSSL actually linked in to the target process, so I can extract struct offsets, member sizes and the like and poke at the right places. I've run into an issue where dwarf_aggregate_size can't calculate the size of an array, when the array is included in a partial CU (DW_TAG_partial_unit). If the array unit includes a DW_AT_upper_bound attribute, but not a DW_AT_lower_bound attribute, then dwarf_aggregate_size will infer the lower bound based on the DW_AT_language attribute of the enclisng CU (i.e. whether the language uses zero or one based indexing). However, the debug symbols I'm looking at for OpenSSL from the Ubuntu repositories have the DW_AT_language on the full compilation unit entries, but not in the partial ones included in them. This means that caling dwarf_aggregate_size on the array type DIE does not work. The DWARF spec doesn't really seem to have anything to say on the matter (all it says is "A full or partial compilation unit entry may have the following attributes", but doesn't say what it logically means if an attribute is present on the complete CU but not a partial one). I guess it doesn't really make sense for a single compilation unit to contain multiple languages? So I wonder if dwarf_srclang (called by dwarf_aggregate_size) should crawl through the list of CU's to see if the DIE's CU is included in a CU that _does_ specify DW_AT_language (recursively, I suppose). Then, we can infer that the partial CU's language is the same as the enclosing one. If people reckon this is a good idea (or, have a better one!), I'm happy to try and put together a patch. KJ