Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fail to work on s390 in Debian #19

Closed
petterreinholdtsen opened this issue Nov 15, 2016 · 9 comments
Closed

Fail to work on s390 in Debian #19

petterreinholdtsen opened this issue Nov 15, 2016 · 9 comments

Comments

@petterreinholdtsen
Copy link
Contributor

The source build but fail to work on s390 when built for Debian. See https://buildd.debian.org/status/fetch.php?pkg=libelfin&arch=s390x&ver=0.2-5&stamp=1479224801 for the complete build log. This is the error:

PASS dump-segments golden-gcc-4.9.2/example
FAIL dump-lines golden-gcc-4.9.2/example
	./test.sh: line 24: 24954 Aborted                 ../examples/dump-$dump golden-$compiler/$binary 1>&$output.out
	failed: exit status 134
	--- golden-gcc-4.9.2/lines	2016-09-28 18:00:31.000000000 +0000
	+++ /tmp/libelfin.iav8gPN88i.out	2016-11-15 15:46:34.004275388 +0000
	@@ -1,10 +1,2 @@
	---- <0>
	-x/example.c                                    2            0x4004b6
	-x/example.c                                    3            0x4004c2
	-x/example.c                                    4            0x4004c8
	-x/example.c                                    5            0x4004cd
	-x/example.c                                    6            0x4004eb
	-x/example.c                                    9            0x4004f2
	-x/example.c                                   10            0x400501
	-x/example.c                                   11            0x40050b
	-
	+terminate called after throwing an instance of 'dwarf::format_error'
	+  what():  unknown compilation unit version 1024
PASS dump-syms golden-gcc-4.9.2/example
FAIL dump-tree golden-gcc-4.9.2/example
	./test.sh: line 24: 24959 Aborted                 ../examples/dump-$dump golden-$compiler/$binary 1>&$output.out
	failed: exit status 134
	--- golden-gcc-4.9.2/tree	2016-09-28 18:00:31.000000000 +0000
	+++ /tmp/libelfin.iav8gPN88i.out	2016-11-15 15:46:34.012275388 +0000
	@@ -1,65 +1,2 @@
	---- <0>
	-<b> DW_TAG_compile_unit
	-      DW_AT_producer GNU C 4.9.2 -mtune=generic -march=x86-64 -g -fdebug-prefix-map=/home/amthrax/r/libelfin/test=x
	-      DW_AT_language 0x1
	-      DW_AT_name example.c
	-      DW_AT_comp_dir x
	-      DW_AT_low_pc 0x4004b6
	-      DW_AT_high_pc 0x57
	-      DW_AT_stmt_list <line 0x0>
	- <2b> DW_TAG_subprogram
	-       DW_AT_external true
	-       DW_AT_name fib
	-       DW_AT_decl_file 0x1
	-       DW_AT_decl_line 0x1
	-       DW_AT_prototyped true
	-       DW_AT_type <0x59>
	-       DW_AT_low_pc 0x4004b6
	-       DW_AT_high_pc 0x3c
	-       DW_AT_frame_base <exprloc>
	-       (DW_AT)0x2116 true
	-       DW_AT_sibling <0x59>
	-  <4c> DW_TAG_formal_parameter
	-        DW_AT_name x
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x1
	-        DW_AT_type <0x59>
	-        DW_AT_location <exprloc>
	- <59> DW_TAG_base_type
	-       DW_AT_byte_size 0x4
	-       DW_AT_encoding 0x5
	-       DW_AT_name int
	- <60> DW_TAG_subprogram
	-       DW_AT_external true
	-       DW_AT_name main
	-       DW_AT_decl_file 0x1
	-       DW_AT_decl_line 0x8
	-       DW_AT_prototyped true
	-       DW_AT_type <0x59>
	-       DW_AT_low_pc 0x4004f2
	-       DW_AT_high_pc 0x1b
	-       DW_AT_frame_base <exprloc>
	-       (DW_AT)0x2116 true
	-       DW_AT_sibling <0x9e>
	-  <81> DW_TAG_formal_parameter
	-        DW_AT_name argc
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x8
	-        DW_AT_type <0x59>
	-        DW_AT_location <exprloc>
	-  <8f> DW_TAG_formal_parameter
	-        DW_AT_name argv
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x8
	-        DW_AT_type <0x9e>
	-        DW_AT_location <exprloc>
	- <9e> DW_TAG_pointer_type
	-       DW_AT_byte_size 0x8
	-       DW_AT_type <0xa4>
	- <a4> DW_TAG_pointer_type
	-       DW_AT_byte_size 0x8
	-       DW_AT_type <0xaa>
	- <aa> DW_TAG_base_type
	-       DW_AT_byte_size 0x1
	-       DW_AT_encoding 0x6
	-       DW_AT_name char
	+terminate called after throwing an instance of 'dwarf::format_error'
	+  what():  unknown compilation unit version 1024
2 test(s) failed

Thank you very much for providing the self test in the code. It avoided uploading broken binaries to Debian. :)
@petterreinholdtsen
Copy link
Contributor Author

Note, it failed on at least hppa and powerpc too. See https://buildd.debian.org/status/package.php?p=libelfin&suite=unstable for a complete list. Endian problem?

@petterreinholdtsen
Copy link
Contributor Author

This issue is tracked as https://bugs.debian.org/844465 in Debian.

@aclements
Copy link
Owner

libelf++ supports non-native byte orders, but I never implemented this for libdwarf++. I'm not sure when I'll get around to this (patches welcome). However, a helpful first step someone else could do would be to build test/example.c on a big endian machine using gcc -g -fdebug-prefix-map=$PWD=x example.c (from test/golden-gcc-4.9.2/NOTES) and post the binary and gcc -v.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Nov 30, 2016 via email

aclements pushed a commit that referenced this issue Dec 2, 2016
elf: fix Shdr.link for big-endian byte order
666596b 
The section number type is declared as a Half (uint16_t) because
that's the right size for Sym, but the link field section number in
Shdr is actually a Word (uint32_t). This works out find on
little-endian because the padding inserted by the compiler is in the
right place, but on big-endian the padding is on the wrong side of
this field, so the link field is always 0 in practice.

Fix this by using the real "shn" type if the byte order is "native",
and using Word if the byte order is big or little endian,

Updates #19.
@aclements
Copy link
Owner

@petterreinholdtsen, I think this should do it, but can you test on a big endian machine? I was able to confirm that my little endian machine was able to process the big endian binary, which strongly suggests that this should work, but there could still be bugs.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Dec 2, 2016 via email

@petterreinholdtsen
Copy link
Contributor Author

Btw, looking at the code and the files in test/golden-gcc-*/ make me suspect the test will fail when a new compiler show up or for all architectures that do not have its own directory there. Is this correct? There are as mentioned earlier several big endian architectures in Debian, and I worry that the current fixes only make the s390x build work, while the others will keep failing.

@aclements
Copy link
Owner

I hope you can make a new release soon with this change, and We'll get
it into Debian as soon as possible after this.

Release v0.3 created.

Btw, looking at the code and the files in test/golden-gcc-*/ make me suspect the test will fail when a new compiler show up or for all architectures that do not have its own directory there. Is this correct?

No, this shouldn't be a problem. For example, I ran the 6.2.1-s390x tests on my x86 machine that doesn't have GCC 6.2.1. Since the test binaries are already made, it doesn't matter what architecture is running them or what compilers are available.

@petterreinholdtsen
Copy link
Contributor Author

petterreinholdtsen commented Dec 3, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@petterreinholdtsen @aclements