[Bug default/26674] New: dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[Bug default/26674] New: dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[annulen at yandex dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=26674

            Bug ID: 26674
           Summary: dwz should be able to fix CRCs in .gnu_debuglink when
                    optimizing separated debug files
           Product: dwz
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: nobody at sourceware dot org
          Reporter: annulen at yandex dot ru
                CC: dwz at sourceware dot org
  Target Milestone: ---

Right now optimizing standalone debug files which were extracted from main ELF
files via objcopy prevents their use in gdb because .gnu_debuglink of main ELF
file has CRC which was not updated. It would be great if dwz could fix CRC
itself (path of main ELF file can be given through additional command line
argument), or at least provided separate tool for doing such fix (I'm aware of
sepdebugcrcfix but it's a part of rpm and isn't really user-friendly)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26674] dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26674

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Konstantin Tokarev from comment #0)
> tool for doing such
> fix (I'm aware of sepdebugcrcfix but it's a part of rpm and isn't really
> user-friendly)

Well, I know this method: you remove the section, and then add it back using
objcopy:
...
$ objcopy -R .gnu_debuglink a.out
$ objcopy --add-gnu-debuglink=a.debug a.out
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26674] dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26674

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26674] dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[annulen at yandex dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=26674

--- Comment #2 from Konstantin Tokarev <annulen at yandex dot ru> ---
Thanks, I didn't think about that way somehow. However, I still think there is
a room for usability improvement.

I think following way would be the most convenient: 
1) we run dwz on "main" ELF files instead of extracted debug info
2) if .debug_info section is missing dwz optimizes file referenced in
.gnu_debuglink and updates CRC
3) if input file looks like "debug file", i.e. file produced by objcopy
--only-keep-debug, print a suggestion that dwz might need to be run on "main"
file or CRC will be off

In this workflow it would also be possible to use multifile mode without much
hassle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/26674] dwz should be able to fix CRCs in .gnu_debuglink when optimizing separated debug files

[annulen at yandex dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=26674

--- Comment #3 from Konstantin Tokarev <annulen at yandex dot ru> ---
It can be activated with option like --follow-debuglinks to preserve existing
behavior by default

-- 
You are receiving this mail because:
You are on the CC list for the bug.