From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EC13E3858423; Tue, 7 Dec 2021 09:29:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC13E3858423 From: "mark at klomp dot org" To: libabigail@sourceware.org Subject: [Bug default/21023] The abidw tool does not appear to read dwarf from .dwp files associated with executables Date: Tue, 07 Dec 2021 09:29:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:29:30 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21023 --- Comment #10 from Mark Wielaard --- (In reply to Thomas Schwinge from comment #8) > Additionally, in PR25042 I saw Mark's 2019-09-30 comment that "logic [the= re] > is broken, [...] when dealing with split-dwarf DWO files", so I suppose t= hat > needs to be reworked, too? Per Dodji's 2019-10-01 comment, "this > optimization will be unnecessary, hopefully". libdw is designed so you don't need to know the specific DW_FORM that an attribute is encoded in. For strings it expects your simply call dwarf_formstring which provides you with a char * (and libdw takes care of figuring out where precisely this string comes from for you). libabigail however takes advantage of the fact that normally all strings co= me from one section .debug_str which is a unique string pool. That allows some optimizations when comparing strings. But especially with split Dwarf (but also with small strings embedded in .debug_info) there is no longer one .debug_str pool that contains all unique strings (but one per .dwo file). So you might have to go through the code to see where/how strings are compa= red to make sure it still does the right thing given multiple string pools. Maybe if string comparisons are really that important to optimize you'll ha= ve to create a new string pool so you get string pointers/offsets that get you= the most optimal string compare results. --=20 You are receiving this mail because: You are on the CC list for the bug.=