Bug 21193 - objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1
Summary: objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1
Status: ASSIGNED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.29
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-22 14:41 UTC by Richard Biener
Modified: 2017-02-23 08:06 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2017-02-22 14:41:20 UTC
int main(){}
> gcc t.c -g
> objcopy --add-gnu-debuglink=a.out.debug a.out
> readelf -S a.out
...
  [36] .gnu_debuglink    PROGBITS         0000000000000000  00001d90
       0000000000000010  0000000000000000           0     0     1

you can see ALIGN 1.  eu-strip -g creates it with ALIGN 4:

  [31] .gnu_debuglink    PROGBITS         0000000000000000  00001834
       0000000000000010  0000000000000000           0     0     4

and this is what RPMs sepdebugcrcfix expects:

      const uint8_t *zerop = memchr (data->d_buf, '\0', data->d_size);
      const uint8_t *crcp = (zerop == NULL
                             ? NULL
                             : (const uint8_t *) ((uintptr_t) (zerop + 1 + 3)
                                                  & -4));
      if (crcp + 4 != (uint8_t *) data->d_buf + data->d_size)
        {
          raise (SIGSTOP);
          error (0, 0, _("invalid format of section \"%s\" # %zu in \"%s\""),
                 scnname, elf_ndxscn (scn), fname);
          continue;
        }

appearantly also objcopy pads the string part to 4 bytes but the above also
requires alignment (on the libelf representation which honors ALIGN).

I will fix the tool but it would be nice to check the "specification" of
.gnu_debuglink as if that padding implicitely assumes alignment of the
section (why would we pad otherwise?).
Comment 1 cvs-commit@gcc.gnu.org 2017-02-22 17:29:44 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=758d96d834ba725461abf4be36df9f13e0815054

commit 758d96d834ba725461abf4be36df9f13e0815054
Author: Nick Clifton <nickc@redhat.com>
Date:   Wed Feb 22 17:28:33 2017 +0000

    Align .gnu_debuglink sections on a 4-byte boundary.
    
    	PR binutils/21193
    	* opncls.c (bfd_create_gnu_debuglink_section): Give the newly
    	created section 4-byte alignment.
Comment 2 Nick Clifton 2017-02-22 17:32:11 UTC
Hi Richard,

  There is no definitive specification for the .gnu_debuglink section, but I
  think that it is clear that it is meant to be aligned on a 4-byte boundary
  so that the CRC value can be read using 32-bit reads.

  So I have checked in a patch to update the bfd_create_gnu_debuglink_section
  function to add the required alignment.

  Is that sufficient, or is there anything else that needs to be updated ?

Cheers
  Nick
Comment 3 rguenther 2017-02-23 08:06:23 UTC
On Wed, 22 Feb 2017, nickc at redhat dot com wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=21193
> 
> Nick Clifton <nickc at redhat dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>                  CC|                            |nickc at redhat dot com
> 
> --- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
> Hi Richard,
> 
>   There is no definitive specification for the .gnu_debuglink section, but I
>   think that it is clear that it is meant to be aligned on a 4-byte boundary
>   so that the CRC value can be read using 32-bit reads.
> 
>   So I have checked in a patch to update the bfd_create_gnu_debuglink_section
>   function to add the required alignment.
> 
>   Is that sufficient, or is there anything else that needs to be updated ?

I think that's sufficient, can you put it on the 2.28 branch as well?