[Bug binutils/21193] New: objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1

[rguenth at gcc dot gnu.org]

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

            Bug ID: 21193
           Summary: objcopy --add-gnu-debuglink adds .gnu_debuglink with
                    ALIGN 1
           Product: binutils
           Version: 2.29 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

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?).

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