From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127246 invoked by alias); 7 Dec 2019 12:35:36 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 127216 invoked by uid 48); 7 Dec 2019 12:35:32 -0000 From: "vries at gcc dot gnu.org" To: dwz@sourceware.org Subject: [Bug default/25252] dwz: returns exit status 1, causing FTBFS in deal.ii Date: Tue, 01 Jan 2019 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: dwz X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: nobody at sourceware dot org 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: 2019-q4/txt/msg00122.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25252 --- Comment #3 from Tom de Vries --- (In reply to Graham Inggs from comment #2) > > This still exits with 0 on dwz-0.13-branch, so presumably 0.13-3 is > > just some random recent trunk version. >=20 > 0.13 + cherry-picks from trunk, I believe. Debian's changelog [1] for > reference. >=20 Actually, looking at the source, it's an _exact_ match for a recent trunk. > > As for the exit status 1, that's currently the expected result when > > running into the max-die-limit. >=20 > Ah, thank you for the explanation. Passing '-L 100000000' to dwz solves = my > problem. Is there any reason I should not do this? Or should I try to g= et > close to the actual number of DIEs? Dwz has two limits, which are there for execution time/memory usage reasons. Anything bigger than the max-die-limit (-L) is not optimized. Increasing th= at limit may make things slower, and consume more memory. Anything bigger than the low-mem-die-limit (-l) is optimized in a slower and less memory hungry fashion. Also, anything bigger than that is skipped in = the multifile optimization, so the result will be less optimal. In summary, bump the limits to where they're not hit (on trunk, we have -ln= one and -Lnone for that), and if that is not a problem in terms of execution ti= me and memory, you're done. If not, than you can tune the limits to reduce execution time/memory usage to acceptable levels. --=20 You are receiving this mail because: You are on the CC list for the bug.