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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils