http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c1 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Printing |Other Assignee|jsmeix@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com QA Contact|jsmeix@suse.com |qa-bugs@suse.de --- Comment #1 from Johannes Meixner --- This is no "Printing" issue. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c3 Dinar Valeev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com --- Comment #3 from Dinar Valeev --- Marcus, do you have any ideas? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c5 --- Comment #5 from Marcus Meissner --- (so probably the power relocations or section setup is different and not correcty handled by debugedit.c) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 Dinar Valeev changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|openssl build failure due |openssl build failure due |to debugedit segfault on |to debugedit segfault on |ppc64/ppc64le |ppc64le -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c8 --- Comment #8 from Michel Normand --- Created attachment 639843 --> http://bugzilla.suse.com/attachment.cgi?id=639843&action=edit ecp_nistp224.readelf_wi.txt ecp_nistp224.readelf_wi.txt is output of: readelf -wi /mnt/disk3/build-root/standard-ppc64le/home/abuild/rpmbuild/BUILD/openssl-1.0.2c/crypto/ec/ecp_nistp224.o

ecp_nistp224.readelf_wi.txt 2>&1

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

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c9 --- Comment #9 from Ulrich Weigand --- It seems GCC generates inconsistent debug info here: .4byte .LASF173 # DW_AT_name: "felem_reduce" .byte 0x1 # DW_AT_decl_file (ecp_nistp224.c) .2byte 0x235 # DW_AT_decl_line # DW_AT_prototyped .byte 0x1 # DW_AT_inline .4byte 0x11ee # DW_AT_sibling .uleb128 0x1f # (DIE (0x11a6) DW_TAG_formal_parameter) .ascii "out\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (ecp_nistp224.c) .2byte 0x235 # DW_AT_decl_line .4byte 0xd63 # DW_AT_type .uleb128 0x1f # (DIE (0x11b2) DW_TAG_formal_parameter) .ascii "in\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (ecp_nistp224.c) .2byte 0x235 # DW_AT_decl_line .4byte 0x11ee # DW_AT_type .uleb128 0x2e # (DIE (0x11bd) DW_TAG_variable) .4byte .LASF174 # DW_AT_name: "two127p15" .byte 0x1 # DW_AT_decl_file (ecp_nistp224.c) .2byte 0x237 # DW_AT_decl_line .4byte 0x109e # DW_AT_type .uleb128 0x2e # (DIE (0x11c9) DW_TAG_variable) .4byte .LASF175 # DW_AT_name: "two127m71" .byte 0x1 # DW_AT_decl_file (ecp_nistp224.c) .2byte 0x239 # DW_AT_decl_line .4byte 0x109e # DW_AT_type For the local variables in felem_reduce: two127p15, two127m71 etc. GCC emits DIEs using the abbrev code 0x2e. That abbrev is defined as: .uleb128 0x2e # (abbrev code) .uleb128 0x34 # (TAG: DW_TAG_variable) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0x5 # (DW_FORM_data2) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x1c # (DW_AT_const_value) .uleb128 0xa # (DW_FORM_block1) .byte 0 .byte 0 so it should take a DW_FORM_block1 encoded DW_AT_const_value. However, the code emitted by GCC in debug_info *does not emit* anything in place of that DW_FORM_block1 ... Thus the resulting debug section is corrupted. This happens when emitting debug info for: static void felem_reduce(felem out, const widefelem in) { static const widelimb two127p15 = (((widelimb) 1) << 127) + (((widelimb) 1) << 15); static const widelimb two127m71 = (((widelimb) 1) << 127) - (((widelimb) 1) << 71); static const widelimb two127m71m55 = (((widelimb) 1) << 127) - (((widelimb) 1) << 71) - (((widelimb) 1) << 55); where widelimb is a typedef for uint128_t. Since the variable is indeed constant and therefore optimized away, it makes sense to emit a DW_AT_const_value attribute. Since the type is uint128_t, it makes sense to encode the constant value as DW_FORM_block1. However, the actual encoding is then simply missing from the output ... I'll attempt to reproduce this against upstream GCC. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c10 --- Comment #10 from Ulrich Weigand --- Stripped down example: __uint128_t test(void) { static const __uint128_t two127 = ((__uint128_t) 1) << 127; return two127; } built with -O -g -S -dA results in (incorrect): .uleb128 0x3 # (DIE (0x4e) DW_TAG_variable) .4byte .LASF4 # DW_AT_name: "two127" .byte 0x1 # DW_AT_decl_file (xxx.i) .byte 0x4 # DW_AT_decl_line .4byte 0x61 # DW_AT_type .byte 0 # end of children of DIE 0x2d .uleb128 0x3 # (abbrev code) .uleb128 0x34 # (TAG: DW_TAG_variable) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x1c # (DW_AT_const_value) .uleb128 0xa # (DW_FORM_block1) .byte 0 .byte 0 This happens with current mainline and current gcc-5-branch on ppc64le, but for some reason not on x86_64. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c11 --- Comment #11 from Ulrich Weigand ---

This happens with current mainline and current gcc-5-branch on ppc64le, but for some reason not on x86_64.

Actually, it does happen on x86_64 as well, but only on mainline, not in the GCC 5 branch. The bug happens only when CONST_WIDE_INT is being used. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=936563 http://bugzilla.suse.com/show_bug.cgi?id=936563#c13 --- Comment #13 from Michel Normand --- (In reply to Ulrich Weigand from comment #12)

I have opened a GCC bugzilla to track this problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728

Only for information, there is still pending discussion upstream for a proposed patch as per: https://gcc.gnu.org/cgi-bin/search.cgi?form=extended&m=all&q=66728&s=D&ul=/ml/gcc-patches/%25&wm=wrd -- You are receiving this mail because: You are on the CC list for the bug.