From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C60D43858CDA; Sun, 19 Feb 2023 13:23:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C60D43858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676813009; bh=azcOXGMHA6tnnk9Flen7h1OnSvUW5cz5Y4jGOhoeugI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VnnQxCq9/GCI/UW/r/9AJjNfKiHYe0MhCyMH9+oCSaiHLvRsVo0uXYJHW7b822NIJ iU//5MqT3MVp7YI9vCkKaYoZfbBnt5buOvRLnbRCVpWnpDHHpNhJOg3fgOKeYgBsDY oL9ffYQC01r6qBi9E0jURZ2jdSh6OgIDXvALLrig= From: "mark at klomp dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/29584] gdb: support zstd compressed .gnu_debugdata Date: Sun, 19 Feb 2023 13:23:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD 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: unassigned 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29584 --- Comment #7 from Mark Wielaard --- (In reply to Fangrui Song from comment #5) > (In reply to Mark Wielaard from comment #4) > > If we are changing the format, Can't we use standard ELF section compre= ssion? > > That supports zstd these days. Then the .gnu_debugdata can be just a no= rmal > > ELF section, that is a mini-ELF image, which happens to be zstd compres= sed. >=20 > We can do that but it likely doesn't provide an overall advantage. > > The .gnu_debugdata content is an ELF file, not a regular section. > We don't benefit from information like ch_type/ch_size/ch_addrline > in the Chdr header. I think it does provide an advantage because programs already need to handle standard compressed Elf sections, so they don't need any special code for decompressing this (assuming we'll drop the old compression scheme eventual= ly). > To embed an ELF file (with .symtab, .strtab, and optionally .debug_*), we > need > one `objcopy --add-section` command, then one `eu-elfcompress -n` command > (with > no binutils equivalent > https://sourceware.org/bugzilla/show_bug.cgi?id=3D27452). > Even eu-elfcompress -n doesn't provide the various zstd options that a > distribution may toggle. There is already support in eu-elfcompress, it will show up in the next rel= ease (0.189, hopefully later this month): -n, --name=3DSECTION SECTION name to (de)compress, SECTION is an extended wildcard pattern (defaults to '.?(z)debug*') [...] -t, --type=3DTYPE What type of compression to apply. TYPE can = be 'none' (decompress), 'zlib' (ELF ZLIB compress= ion, the default, 'zlib-gabi' is an alias), 'zlib-g= nu' (.zdebug GNU style compression, 'gnu' is an al= ias) or 'zstd' (ELF ZSTD compression) > Also, this process involves two binary manipulation commands on > the ELF file. >=20 > If we use `zstd a.debug; objcopy -S > --add-section=3D.gnu_debugdata=3Da.debug.zstd a a.stripped`, > there is just one binary manipulation command, and we can toggle zstd > options easily. It is slightly more that that. See debugedit find-debuginfo add_mini how the section is created: https://sourceware.org/git/?p=3Ddebugedit.git;a=3Dblob;f=3Dscripts/find-deb= uginfo.in;hb=3DHEAD#l332 --=20 You are receiving this mail because: You are on the CC list for the bug.=