From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60430 invoked by alias); 8 Feb 2017 14:17:10 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 59576 invoked by uid 48); 8 Feb 2017 14:16:56 -0000 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: Sun, 01 Jan 2017 00:00:00 -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: UNCONFIRMED 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-SW-Source: 2017-q1/txt/msg00030.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21023 --- Comment #4 from Mark Wielaard --- (In reply to andrew.c.morrow from comment #3) > Thank you for clarifying. It sounds from your description like this will > eventually work automatically, which is great. It will however take some work, it is not really trivial to support. Also w= hile GNU DebugFission is being standardized in the upcoming DWARFv5 there have b= een various changes. So it isn't clear yet which tools will support which versi= on. > I have experimented with dwz as well, with the aim of reducing the size of > our debug symbol packages, but so far without success: > https://bugzilla.redhat.com/show_bug.cgi?id=3D1399866. If you have any > additional thoughts on that ticket it would be greatly appreciated. I sti= ll > don't have an explanation for why dwz cannot process the output of ld.gol= d. I commented on that bug report. It looks like the linker is creating a bogus .bss section, but there is not really enough information in the bug report = to know for sure. > I'm also unclear on the intended relationship between dwp and dwz. When I > tried running dwz on dwp files, my recollection is that it didn't work, at > all. I'd presume that the process would be to collect the .dwo files > associated with each binary into a .dwp file for that binary with the dwp > tool, and then run dwz across all the dwp files to extract common symbols > into a shared file, along with any other optimization/compression. I would > then hope that abidw run on the binary would be able to present the full > ABI, extracting information from both the associated .dwp file, and any > common underling file produced by dwz. >=20 > Or, perhaps the functionality of dwz should be folded directly into dwp? = The > documentation on these tools and the intended direction for development is > somewhat unclear to me. The have been developed completely independently and I don't think anybody = has really thought about how to combine them. They also serve somewhat different purposes. And not many tools support both DWARF debuginfo data/file variant= s. --=20 You are receiving this mail because: You are on the CC list for the bug.