Menu
▾
▴
#90 Support for ppc64le
Hello, I am trying to port UPX for ppc64le system. Using current powerpc 32 bits files and some changes I can compress and decompress binaries - first step done.
As suspected, compressed binary doesn't execute so I believe the stubs must be rewritten for 64bits - what should be done or provided for that ?
Related
Found that changing PAGE_SIZE to 64K solved first mmap() issue.
Not sure of what is next (doc seem to be outdated)
Please state which operating system and its version number. The first step for debugging the stub which executes immediately after execve() is to check that system calls are executed in the correct sequence. So compare the output from strace with a known good system, such as x86_64. Cache flushing is one likely area for bugs. Besides that, single-step by instruction ('stepi' in gdb) is the general method for debugging. Often it helps to generate the stub with a deliberate compiled-in breakpoint or illegal instruction ("teq 0,0,n" [trap #n if equal r0, r0] or similar comes to mind). If you can, please attach a small example program, both uncompressed and compressed; see the active link "Add attachments" on this form. "int x[10000] = {1,2,3}; main() { return x[2]; }" might be a suitable test program.
Assigned to John, as he is our linux/elf maintainer.
Hello,
I made progress and have powerpc (32bits) now running on ppc64 systems.
For 64bits system I am facing 32bits-> 64bits conversion issues related to overflow handling because if I don't see the logic of what it is done with the bytes being loaded - practically if I understand that in 32bits 0x80000000 is the limit of unsigned word, what does the value 0x500 represent ?
0x500 is the boundary of backwards distance at which the minimum match length changes from 2 bytes to 3 bytes. It is an absolute constant that never changes regardless of 32- or 64-bit addresses.
Hello,
I will soon send you a patch for powerpc 32 bits to allow dynamic use of
4K (old powerpc proc) or 64K (new powerpc).
On ppc64le, using -fPic -pic compilation I am still facing an issue after
brk() in ld.so.2 it is using and area @ 0x300000000 which is not
allocated. If I do allocate it manually, I get an error like
"Inconsistency detected by ld.so: rtld.c: 1154: dl_main: Assertion
`GL(dl_rtld_map)."
Have you have any idea where to look for such issue ? in
ppc64le-linux-elf-main.c which would be much different from other
platforms ? or would it be more at time of creation in p_lx_elf.cpp in
canPack() ?
Thanks iin advance fro your adive and help
Regards
--
Thierry Fauck @ linux.vnet.ibm
Hello,
I have fixed the ppc64le port for static binaries.
Trying to look at dynamically linked binaries - is it fully supported ? More precisely, your simple example always fails with message "NotCompressibleException " (even on x86_64 platform), and debugging upx.out compressed by itself is kind of nightmare ! Any idea ? thx
Dynamically linked libraries have additional requirements. See p_lx_elf.cpp near line 1479, "// Heuristic HACK for shared libraries ..."
x86_64 is a CPU architecture that is used by both Linux and MacOSX; which one(s) gave the "not CompresibleException"? Please [gzip and] upload a testcase which gets this error; see the "Add attachments" web link near the bottom of this SourceForge form.
UPX developers never debug self-compressed upx.out. We debug uncompressed upx.out using gdb with source code available.
Hello - thanks for the replys
I will investigate on powerpc (32bits) and powerpc64le the dynamic linked case....
As for the case on x86_64 it is on Linux
$ uname -a
Linux W520 3.19.0-60-generic #67~14.04.1-Ubuntu SMP Wed May 18 17:22:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat testupx.c
int x[10000] = {1,2,3}; main() { return x[2]; }
$ gcc -o testupx testupx.c
$ ./upx.out -o testupx.cmp ./testupx
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2013
UPX 3.91 Markus Oberhumer, Laszlo Molnar & John Reiser Sep 30th 2013
-------------------- ------ ----------- -----------
upx.out: ./testupx: NotCompressibleException
Packed 1 file: 0 ok, 1 error.
We reach that case in Packer::compressWithFilters() because
best_ph.c_len + best_ph_lsize==best_ph.u_len
Let me know if you need anything more.
The .text is too small: there is no gain in compressing it, so upx decides that the file is not worth compressing.
If the array is made 'const' so that it resides in .text, then upx will compress the executable:
Good catch - test is usefull now ... I can debug
(see discussion #378)
Hello,
As I have finished first part of support for ppc64le arch it sounds an idea to sent the patch for review to your team. However I am not too sure which code I need to use as base as
hg clone http://hg.code.sf.net/p/upx/code upx-code
provides a tree older than the current 3.91 tar file.
Do you expect a diff -urN from tar file or do you have a tree that I can clone and apply the changes to it ?
Thanks
The current master source is https://www.pysol.org:4443/hg/upx.hg
because some years ago SourceForge had problems.
Would you mind having a look at this patch and tell me if you need anything more. This patch only provides support for ppc64le statically linked binaries. I am planning to work on the following issues:
Thank you for posting the patch. I have integrated the patch into the UPX sources and pushed the changes to the source code repository. I had to undo this bug in linker.cpp:
and restore the "STUBS +=" for the other architectures in stub/Makefile.
UPX aims for high portability, specifically including reproducible builds of UPX itself, which means that upxbinutils furnishes specific compilers, assemblers, linkers. Unfortunately we lack a C compiler for ppc64le and for aarch64. I have used the cross-compilers from Fedora 22, such as gcc-ppc64-linux-gnu-5.3.1-2.fc22.x86_64.
Supporting compression of shared libraries is somewhat risky because GNU ld and rtld reserve the right to change layout at any time. On the other hand, there is not so much difference betwee -fPIC and -fPIE, and supporting position-independent main executables is desirable.
Hello - As for the STUBS, sorry I forgot do do it. As for the input[inputlen] I should have search why my fellow did that - so of course, thx.
I will push an update for powerpc to dynamically get the PAGESIZE for old powerpc compatibility (like power4) and new powerpc (P7 Bigendian 32bits OS).
As for upxbinutils, I will have a look but must admit I did use what was easy for me... I have been using a Fedora 22 ppc64 to verify the BE ppc32 code.
As for -fpie I also have issues on powerpc (old and new), something is wrong after munmap() and brk() - On ppc64le, sequence to load ld.so.2 being different I have less progressed, but I am still learning (my undertanding of GDB and making a powerfull trace tool with GDB is very good .. just take time to use it !). Thanks
On ppc64le, using -fPic -pic compilation I am still facing an issue after
brk() in ld.so.2 it is using and area @ 0x300000000 which is not allocated. If I do allocate it manually, I get an error like "Inconsistency detected by ld.so: rtld.c: 1154: dl_main: Assertion `GL(dl_rtld_map)."
Have you have any idea where to look for such issue ? in ppc64le-linux-elf-main.c which would be much different from other platforms ? or would it be more at time of creation in p_lx_elf.cpp in canPack() ?
I assume that "using -fPic -pic compilation" means that you have an application that was compiled and linked that way, and the app was compressed by upx, and when running the compressed app then you see the complaint from dl_main in ld.so: rtld.c.
Please post the output from "readelf --segments --dynamic my_app", both before and after upx compression. Also please post the output from "uname -a" and "ls -l /lib*/libc.so.6". Finally, run the compressed app under a debugger such as gdb; when the error occurs then go to another terminal window, run "cat /proc/PID/maps", and post the output (PID is the numeric process ID in which the error occurs.) Thank you.
Hello here are respectively the output of the compressed and original file:
find /lib /usr -name libc.so* -ls
917726 0 lrwxrwxrwx 1 root root 12 Apr 14 16:43 /lib/powerpc64le-linux-gnu/libc.so.6 -> libc-2.23.so
141353 0 lrwxrwxrwx 1 root root 12 Apr 15 21:30 /usr/powerpc-linux-gnu/lib/libc.so.6 -> libc-2.23.so
141272 4 -rw-r--r-- 1 root root 297 Apr 15 21:30 /usr/powerpc-linux-gnu/lib/libc.so
131118 4 -rw-r--r-- 1 root root 305 Apr 14 16:42 /usr/lib/powerpc64le-linux-gnu/libc.so
$ uname -a
Linux vm76 4.3.0-5-generic #16-Ubuntu SMP Wed Dec 16 23:32:23 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
ubuntu@vm76:~/UPX/upx-code/src$ readelf --segments --dynamic ./f_pic
File: ./f_pic
Elf file type is EXEC (Executable file)
Entry point 0x1005f8
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000100000 0x0000000000100000
0x0000000000000fd6 0x0000000000000fd6 R E 10000
LOAD 0x0000000000000038 0x0000000010020038 0x0000000010020038
0x0000000000000000 0x0000000000000000 RW 10000
There is no dynamic section in this file.
ubuntu@vm76:~/UPX/upx-code/src$ readelf --segments --dynamic ~/hello_64le_pic
File: /home/ubuntu/hello_64le_pic
Elf file type is EXEC (Executable file)
Entry point 0x10000400
There are 8 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000010000040 0x0000000010000040
0x00000000000001c0 0x00000000000001c0 R E 8
INTERP 0x0000000000000200 0x0000000010000200 0x0000000010000200
0x0000000000000011 0x0000000000000011 R 1
[Requesting program interpreter: /lib64/ld64.so.2]
LOAD 0x0000000000000000 0x0000000010000000 0x0000000010000000
0x000000000000a474 0x000000000000a474 R E 10000
LOAD 0x000000000000fcf8 0x000000001001fcf8 0x000000001001fcf8
0x0000000000000338 0x0000000000000340 RW 10000
DYNAMIC 0x000000000000fd10 0x000000001001fd10 0x000000001001fd10
0x00000000000001f0 0x00000000000001f0 RW 8
NOTE 0x0000000000000214 0x0000000010000214 0x0000000010000214
0x0000000000000044 0x0000000000000044 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
GNU_RELRO 0x000000000000fcf8 0x000000001001fcf8 0x000000001001fcf8
0x0000000000000308 0x0000000000000308 R 1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame
03 .init_array .fini_array .jcr .dynamic .got .plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06
07 .init_array .fini_array .jcr .dynamic .got
Dynamic section at offset 0xfd10 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x10000388
0x000000000000000d (FINI) 0x10000788
0x0000000000000019 (INIT_ARRAY) 0x1001fcf8
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x1001fd00
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x10000258
0x0000000000000005 (STRTAB) 0x100002d8
0x0000000000000006 (SYMTAB) 0x10000278
0x000000000000000a (STRSZ) 60 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x10020000
0x0000000000000002 (PLTRELSZ) 48 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x10000358
0x0000000070000000 (PPC64_GLINK) 0x10000760
0x0000000070000003 (PPC64_OPT) 0x0
0x0000000000000007 (RELA) 0x10000340
0x0000000000000008 (RELASZ) 24 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x10000320
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x10000314
0x0000000000000000 (NULL) 0x0
$ ps -edf |grep gdb
ubuntu 3802 8099 0 09:32 pts/0 00:00:00 gdb ./f_pic
ubuntu 3823 9318 0 09:35 pts/2 00:00:00 grep --color=auto gdb
ubuntu 29231 8347 0 Aug29 pts/1 00:00:00 gdb ./f_pic
ubuntu@vm76:~/UPX/upx-code/src$ cat /proc/29231/maps
10000000-108b0000 r-xp 00000000 08:02 133285 /usr/bin/gdb
108c0000-10900000 r--p 008b0000 08:02 133285 /usr/bin/gdb
10900000-10940000 rw-p 008f0000 08:02 133285 /usr/bin/gdb
10940000-10960000 rw-p 00000000 00:00 0
10034210000-100346e0000 rw-p 00000000 00:00 0 [heap]
3fffa9230000-3fffa9270000 rw-p 00000000 00:00 0
3fffa92b0000-3fffa92f0000 rw-p 00000000 00:00 0
3fffa9330000-3fffa95f0000 rw-p 00000000 00:00 0
3fffa95f0000-3fffa98d0000 r--p 00000000 08:02 141371 /usr/lib/locale/locale-archive
3fffa98d0000-3fffa98e0000 r-xp 00000000 08:02 917684 /lib/powerpc64le-linux-gnu/libutil-2.23.so
3fffa98e0000-3fffa98f0000 r--p 00000000 08:02 917684 /lib/powerpc64le-linux-gnu/libutil-2.23.so
3fffa98f0000-3fffa9900000 rw-p 00010000 08:02 917684 /lib/powerpc64le-linux-gnu/libutil-2.23.so
3fffa9900000-3fffa9ac0000 r-xp 00000000 08:02 917690 /lib/powerpc64le-linux-gnu/libc-2.23.so
3fffa9ac0000-3fffa9ad0000 r--p 001b0000 08:02 917690 /lib/powerpc64le-linux-gnu/libc-2.23.so
3fffa9ad0000-3fffa9ae0000 rw-p 001c0000 08:02 917690 /lib/powerpc64le-linux-gnu/libc-2.23.so
3fffa9ae0000-3fffa9b10000 r-xp 00000000 08:02 917579 /lib/powerpc64le-linux-gnu/liblzma.so.5.0.0
3fffa9b10000-3fffa9b20000 rw-p 00020000 08:02 917579 /lib/powerpc64le-linux-gnu/liblzma.so.5.0.0
3fffa9b20000-3fffa9b60000 r-xp 00000000 08:02 917540 /lib/powerpc64le-linux-gnu/libexpat.so.1.6.0
3fffa9b60000-3fffa9b70000 r--p 00030000 08:02 917540 /lib/powerpc64le-linux-gnu/libexpat.so.1.6.0
3fffa9b70000-3fffa9b80000 rw-p 00040000 08:02 917540 /lib/powerpc64le-linux-gnu/libexpat.so.1.6.0
3fffa9b80000-3fffa9ba0000 r-xp 00000000 08:02 917682 /lib/powerpc64le-linux-gnu/libpthread-2.23.so
3fffa9ba0000-3fffa9bb0000 r--p 00010000 08:02 917682 /lib/powerpc64le-linux-gnu/libpthread-2.23.so
3fffa9bb0000-3fffa9bc0000 rw-p 00020000 08:02 917682 /lib/powerpc64le-linux-gnu/libpthread-2.23.so
3fffa9bc0000-3fffa9ff0000 r-xp 00000000 08:02 144817 /usr/lib/powerpc64le-linux-gnu/libpython3.5m.so.1.0
3fffa9ff0000-3fffaa000000 ---p 00430000 08:02 144817 /usr/lib/powerpc64le-linux-gnu/libpython3.5m.so.1.0
3fffaa000000-3fffaa010000 r--p 00430000 08:02 144817 /usr/lib/powerpc64le-linux-gnu/libpython3.5m.so.1.0
3fffaa010000-3fffaa0b0000 rw-p 00440000 08:02 144817 /usr/lib/powerpc64le-linux-gnu/libpython3.5m.so.1.0
3fffaa0b0000-3fffaa0e0000 rw-p 00000000 00:00 0
3fffaa0e0000-3fffaa1b0000 r-xp 00000000 08:02 917693 /lib/powerpc64le-linux-gnu/libm-2.23.so
3fffaa1b0000-3fffaa1c0000 r--p 000c0000 08:02 917693 /lib/powerpc64le-linux-gnu/libm-2.23.so
3fffaa1c0000-3fffaa1d0000 rw-p 000d0000 08:02 917693 /lib/powerpc64le-linux-gnu/libm-2.23.so
3fffaa1d0000-3fffaa200000 r-xp 00000000 08:02 917581 /lib/powerpc64le-linux-gnu/libtinfo.so.5.9
3fffaa200000-3fffaa210000 r--p 00020000 08:02 917581 /lib/powerpc64le-linux-gnu/libtinfo.so.5.9
3fffaa210000-3fffaa220000 rw-p 00030000 08:02 917581 /lib/powerpc64le-linux-gnu/libtinfo.so.5.9
3fffaa220000-3fffaa250000 r-xp 00000000 08:02 917709 /lib/powerpc64le-linux-gnu/libncurses.so.5.9
3fffaa250000-3fffaa260000 r--p 00020000 08:02 917709 /lib/powerpc64le-linux-gnu/libncurses.so.5.9
3fffaa260000-3fffaa270000 rw-p 00030000 08:02 917709 /lib/powerpc64le-linux-gnu/libncurses.so.5.9
3fffaa270000-3fffaa280000 r-xp 00000000 08:02 917706 /lib/powerpc64le-linux-gnu/libdl-2.23.so
3fffaa280000-3fffaa290000 r--p 00000000 08:02 917706 /lib/powerpc64le-linux-gnu/libdl-2.23.so
3fffaa290000-3fffaa2a0000 rw-p 00010000 08:02 917706 /lib/powerpc64le-linux-gnu/libdl-2.23.so
3fffaa2a0000-3fffaa2c0000 r-xp 00000000 08:02 917731 /lib/powerpc64le-linux-gnu/libz.so.1.2.8
3fffaa2c0000-3fffaa2d0000 r--p 00010000 08:02 917731 /lib/powerpc64le-linux-gnu/libz.so.1.2.8
3fffaa2d0000-3fffaa2e0000 rw-p 00020000 08:02 917731 /lib/powerpc64le-linux-gnu/libz.so.1.2.8
3fffaa2e0000-3fffaa330000 r-xp 00000000 08:02 917647 /lib/powerpc64le-linux-gnu/libreadline.so.6.3
3fffaa330000-3fffaa340000 r--p 00040000 08:02 917647 /lib/powerpc64le-linux-gnu/libreadline.so.6.3
3fffaa340000-3fffaa350000 rw-p 00050000 08:02 917647 /lib/powerpc64le-linux-gnu/libreadline.so.6.3
3fffaa360000-3fffaa370000 r--s 00000000 08:02 157680 /usr/lib/powerpc64le-linux-gnu/gconv/gconv-modules.cache
3fffaa370000-3fffaa390000 r-xp 00000000 00:00 0 [vdso]
3fffaa390000-3fffaa3d0000 r-xp 00000000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffaa3d0000-3fffaa3e0000 r--p 00030000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffaa3e0000-3fffaa3f0000 rw-p 00040000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffd02c0000-3fffd02f0000 rw-p 00000000 00:00 0 [stack]
Houps...previous output not accurate, think this one is better
0x3fffb7f94e5c std r31,40(r31)
r3 0x300000048 12884901960
(gdb) info inferiors
Num Description Executable
$ cat /proc/3809/maps
cat: /proc/3809/maps: No such file or directory
ubuntu@vm76:~/UPX/upx-code/src$ cat /proc/3838/maps
00110000-00120000 rwxp 00000000 00:00 0
10000000-10010000 r-xp 00000000 00:00 0
10010000-10030000 rw-p 00000000 00:00 0 [heap]
300000000-300010000 rwxp 00000000 00:00 0 <------ manually allocated
3fffb7f80000-3fffb7fc0000 r-xp 00000000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffb7fc0000-3fffb7fe0000 rw-p 00030000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffb7fe0000-3fffb8000000 r-xp 00000000 00:00 0 [vdso]
3ffffffd0000-400000000000 rw-p 00000000 00:00 0 [stack]
(gdb) c
Continuing.
Inconsistency detected by ld.so: rtld.c: 1154: dl_main: Assertion `GL(dl_rtld_map).l_libname->next == NULL' failed!
[Inferior 1 (process 3838) exited with code 0177]
If I don't allocate that area manually,
ubuntu@vm76:~/UPX/upx-code/src$ cat /proc/3907/maps
00110000-00120000 rwxp 00000000 00:00 0
10000000-10010000 r-xp 00000000 00:00 0
10010000-10030000 rw-p 00000000 00:00 0 [heap]
3fffb7f80000-3fffb7fc0000 r-xp 00000000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffb7fc0000-3fffb7fe0000 rw-p 00030000 08:02 917694 /lib/powerpc64le-linux-gnu/ld-2.23.so
3fffb7fe0000-3fffb8000000 r-xp 00000000 00:00 0 [vdso]
3ffffffd0000-400000000000 rw-p 00000000 00:00 0 [stack]
What is the output from running "strace ./f_pic" using the compressed version? This traces the system calls.
On 05/09/2016 16:12, John Reiser wrote:
if I allocate the area,
$ strace ./f_pic
execve("./f_pic", ["./f_pic"], [/ 23 vars /]) = 0
mmap(0x110000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x110000
mmap(0x10000000, 196608, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x10000000
mmap(0x10000000, 42100, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x10000000
mprotect(0x10000000, 42100, PROT_READ|PROT_EXEC) = 0
mmap(0x10010000, 65584, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x10010000
mprotect(0x10010000, 65584, PROT_READ|PROT_WRITE) = 0
open("/lib64/ld64.so.2", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\25\0\1\0\0\0\240\23\0\0\0\0\0\0"...,
1024) = 1024
mmap(NULL, 393216, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x3fff920b0000
mmap(0x3fff920b0000, 206272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0) = 0x3fff920b0000
mmap(0x3fff920f0000, 69512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x30000) = 0x3fff920f0000
close(3) = 0
munmap(0x100000, 65536) = 0
mmap(0x300000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 3, 0x30000) = 0x300000000
brk(NULL) = 0x10002d80000
brk(NULL) = 0x10002d80000
writev(2, [{"Inconsistency detected by ld.so:"..., 33}, {"rtld.c", 6},
{": ", 2}, {"1154", 4}, {": ", 2}, {"dl_main", 7}, {": ", 2},
{"Assertion
", 11}, {"GL(dl_rtld_map).l_libname->next "..., 39}, {"' failed!\n", 10}], 10Inconsistency detected by ld.so: rtld.c: 1154: dl_main: AssertionGL(dl_rtld_map).l_libname->next == NULL' failed!) = 116
exit_group(127) = ?
+++ exited with 127 +++
--
Thierry Fauck @ linux.vnet.ibm
Related
Feature Requests: #90
Do you get any useful information from running valgrind on the compressed ./f_pic, both with and without manual allocation of the page at 0x300000000? [Running valgrind on a compressed version of /bin/date works for me on x86_64.]
On 05/09/2016 19:55, John Reiser wrote:
and the other (when I allocate region manually)
==4610== Syscall param munmap(start) contains uninitialised byte(s)
==4610== at 0x110180: ???
==4610==
==4610== Syscall param munmap(length) contains uninitialised byte(s)
==4610== at 0x110180: ???
==4610==
==4610==
==4610== Process terminating with default action of signal 11 (SIGSEGV)
==4610== Access not within mapped region at address 0x100040
<--- from strace in fold.S this area has been unmapped
==4610== at 0x4002FCC: dl_main (rtld.c:1021)
==4610== by 0x4029153: _dl_sysdep_start (dl-sysdep.c:249)
==4610== by 0x4001C2F: _dl_start_final (rtld.c:307)
==4610== by 0x40060DF: _dl_start (rtld.c:415)
==4610== by 0x40013B7: _start (in /lib/powerpc64le-linux-gnu/ld-2.23.so)
==4610== If you believe this happened as a result of a stack
==4610== overflow in your program's main thread (unlikely but
==4610== possible), you can try to increase the size of the
==4610== main thread stack using the --main-stacksize= flag.
==4610== The main thread stack size used in this run was 8388608.
==4610==
==4610== HEAP SUMMARY:
==4610== in use at exit: 0 bytes in 0 blocks
==4610== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4610==
==4610== All heap blocks were freed -- no leaks are possible
if I don't deallocate the 0x1000000 area and allocate 0x300000000 I get
==4679== Use of uninitialised value of size 8
==4679== at 0x110568: ???
==4679== by 0x1107EB: ???
==4679== by 0x1100BB: ???
==4679==
==4679== Syscall param close(fd) contains uninitialised byte(s)
==4679== at 0x11017C: ???
==4679== by 0x1100BB: ???
==4679==
==4679== Conditional jump or move depends on uninitialised value(s)
==4679== at 0x110778: ???
==4679== by 0x1100BB: ???
==4679==
Inconsistency detected by ld.so: rtld.c: 1139: dl_main: Assertion
`GL(dl_rtld_map).l_libname' failed!
/Comments: /
As I am lost, here are the only ideas I have in mind
On powerpc it works but the current difference I have found is:
on ppc64le I need to set r12 to the link register value set at end of
call to ppc64le-linux.elf-main.c because that register is used to set
the r31 after a couple of load and displacement in ld.so.2 - that was
much simpler in ld.so.1
and I couldn't find why this value 0x300000004x is set , may be I am
missing something with the load of the ld.so.2
I have thought that ppc64le-linux.elf-main.c could not be correct but
really as it is very similiar for all platforms I doubt - I even tried
some of the current main.c code and nothing changed.
So it could be when we restore all register after call to main.c but
then I don't know why !
For powerpc, I can't run valgrind to compare as:
valgrind ./f_pic
valgrind: mmap(0x100000, 4096) failed in UME with error 22 (Invalid
argument).
valgrind: this can be caused by executables with very large text, data
or bss segments.
--
Thierry Fauck @ linux.vnet.ibm
Related
Feature Requests: #90