Comments (17)
From HEAD
PASS: plain-run.sh
PASS: plain-fail.sh
PASS: set-interpreter-short.sh
PASS: shrink-rpath.sh
FAIL: set-interpreter-long.sh
PASS: soname.sh
FAIL: set-rpath.sh
FAIL: no-rpath.sh
FAIL: big-dynstr.sh
FAIL: set-rpath-library.sh
PASS: no-rpath-armel.sh
FAIL: no-rpath-kfreebsd-i386.sh
FAIL: no-rpath-amd64.sh
PASS: no-rpath-hurd-i386.sh
PASS: no-rpath-kfreebsd-amd64.sh
FAIL: no-rpath-i386.sh
PASS: no-rpath-armhf.sh
PASS: no-rpath-mipsel.sh
PASS: no-rpath-ia64.sh
PASS: no-rpath-mips.sh
PASS: no-rpath-s390.sh
PASS: no-rpath-powerpc.sh
PASS: no-rpath-sparc.sh
PASS: no-rpath-sh4.sh
from patchelf.
Does it fail if you try PR #73 ?
from patchelf.
I'll try it but it says it has to do with foreign binaries and I'm running native aarch64.
from patchelf.
PR #73 didn't affect the outcome.
from patchelf.
OK. I wondered because PowerPC64 also fails without #73 or something
similar (the page size is not 4096 as hardcoded currently).
On 17 February 2016 at 13:30, Michael Fox [email protected] wrote:
PR #73 #73 didn't affect the
outcome.—
Reply to this email directly or view it on GitHub
#79 (comment).
Saludos,
Felipe Sateler
from patchelf.
Flexible page size is definitely an issue for aarch64 so probably on the right track.
On Feb 17, 2016, at 8:32 AM, Felipe Sateler [email protected] wrote:
OK. I wondered because PowerPC64 also fails without #73 or something
similar (the page size is not 4096 as hardcoded currently).On 17 February 2016 at 13:30, Michael Fox [email protected] wrote:
PR #73 #73 didn't affect the
outcome.—
Reply to this email directly or view it on GitHub
#79 (comment).Saludos,
Felipe Sateler
—
Reply to this email directly or view it on GitHub #79 (comment).
from patchelf.
One problem is just I'm running ubuntu and /bin/sh
is not bash which test scripts seem to assume. I don't know why she did this to me.
from patchelf.
One thing that's real though (and critical for nix) is that set-interpreter-long makes a segfaulting program:
++ basename ./set-interpreter-long.sh .sh
+ SCRATCH=scratch/set-interpreter-long
+ ./simple
Hello World
++ ../src/patchelf --print-interpreter ./simple
+ oldInterpreter=/lib/ld-linux-aarch64.so.1
+ echo 'current interpreter is /lib/ld-linux-aarch64.so.1'
current interpreter is /lib/ld-linux-aarch64.so.1
++ uname
+ test Linux = Linux
+ echo 'running with explicit interpreter...'
running with explicit interpreter...
+ /lib/ld-linux-aarch64.so.1 ./simple
Hello World
+ rm -rf scratch/set-interpreter-long
+ mkdir -p scratch/set-interpreter-long
++ pwd
+ newInterpreter=/home/admin/nix-boot/patchelf2/tests/scratch/set-interpreter-long/iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
+ cp simple scratch/set-interpreter-long/
+ ../src/patchelf --set-interpreter /home/admin/nix-boot/patchelf2/tests/scratch/set-interpreter-long/iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii scratch/set-interpreter-long/simple
+ echo 'running with missing interpreter...'
running with missing interpreter...
+ scratch/set-interpreter-long/simple
./set-interpreter-long.sh: line 23: scratch/set-interpreter-long/simple: No such file or directory
+ echo 'running with new interpreter...'
running with new interpreter...
+ ln -s /lib/ld-linux-aarch64.so.1 /home/admin/nix-boot/patchelf2/tests/scratch/set-interpreter-long/iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
+ scratch/set-interpreter-long/simple
./set-interpreter-long.sh: line 30: 13767 Segmentation fault ${SCRATCH}/simple
from patchelf.
Double checked with #73 and darn, no help.
from patchelf.
I have something that works here: #80
The problem is that it breaks cross-architecture patching of elfs. It only helps to make sure you use the page-size of the kernel you are currently running. So a native aarch64 can patch it's own elfs but x86 can't cross-build aarch64.
What we need
Is to detect the kernel page size from the elf itself.
Can it be done? I was hoping not to have to learn too much about elfs today, but I guess that didn't work out for me. I'll find out and let you know.
The only other way would be to make target kernel page size an explicit parameter for patchelf. Not a big deal in itself, but updating all of nix/nixpkgs/nixos to support this is mind-boggling.
from patchelf.
Current master picks up the native page size at build time, and you can
specify the page size on the command line, but I thought that didn't work
for you?
On 28 Feb 2016 13:35, "Michael Fox" [email protected] wrote:
I have something that works here: #80
#80The problem is that it breaks cross-architecture patching of elfs. It only
helps to make sure you use the page-size of the kernel you are currently
running. So a native aarch64 can patch it's own elfs but x86 can't
cross-build aarch64.
What we needIs to detect the kernel page size from the elf itself.
Can it be done? I was hoping not to have to learn too much about elfs
today, but I guess that didn't work out for me. I'll find out and let you
know.The only other way would be to make target kernel page size an explicit
parameter for patchelf. Not a big deal in itself, but updating all of
nix/nixpkgs/nixos to support this is mind-boggling.—
Reply to this email directly or view it on GitHub
#79 (comment).
from patchelf.
Relevant: https://www.kernel.org/doc/Documentation/arm64/memory.txt
AArch64 Linux uses either 3 levels or 4 levels of translation tables
with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
(256TB) virtual addresses, respectively, for both user and kernel. With
64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
virtual address, are used but the memory layout is the same.
http://man7.org/linux/man-pages/man5/elf.5.html
p_align This member holds the value to which the segments are
aligned in memory and in the file. Loadable process
segments must have congruent values for p_vaddr and
p_offset, modulo the page size. Values of zero and one
mean no alignment is required. Otherwise, p_align should
be a positive, integral power of two, and p_vaddr should
equal p_offset, modulo p_align.
from patchelf.
I did it! Hooray for me! #80 now passes all tests under aarch64 and amd64.
What's needed is:
- More extensive testing (I will build nixos under aarch64 eventually)
- More architectures added to getPageSize() function
It would be good to find a more elegant solution, but the thing for now is to use the machine type from the elf header to decide the page size.
from patchelf.
@fsateler I guess that works fine for me. I just didn't know about it.
However, I still think it will be more convenient if page size can be reliably predicted from the ELF file itself. I guess we're already discussing this in #80
from patchelf.
Well, the pagesize is determined at build time by the OS configuration, so
most use cases should be handled fine. Apparently there is no easy way to
determine the page size of a given elf binary, and this works enough for
me, so I've not looked further into it.
On 2 March 2016 at 16:39, Michael Fox [email protected] wrote:
@fsateler https://github.com/fsateler I guess that works fine for me. I
just didn't know about it.However, I still think it will be more convenient if page size can be
reliably predicted from the ELF file itself. I guess we're already
discussing this in #80 #80—
Reply to this email directly or view it on GitHub
#79 (comment).
Saludos,
Felipe Sateler
from patchelf.
Most use cases are good, but I think the case of cross-compiling is broken.
The user needs to know what the target page size is and needs to know that
there's such thing as page size (I didn't).
My idea is to look at the target elf which is contained in the elf header
and make a conservative decision.
For example aarch64 can have 4k or 64k page size. It's conservative to just
use 64k since the target should work either way.
I might be missing something because I'm not sure all the ways patchelf
uses the page size. Seems like a lot of different things.
On Wed, Mar 2, 2016 at 11:47 AM, Felipe Sateler [email protected]
wrote:
Well, the pagesize is determined at build time by the OS configuration, so
most use cases should be handled fine. Apparently there is no easy way to
determine the page size of a given elf binary, and this works enough for
me, so I've not looked further into it.On 2 March 2016 at 16:39, Michael Fox [email protected] wrote:
@fsateler https://github.com/fsateler I guess that works fine for me.
I
just didn't know about it.However, I still think it will be more convenient if page size can be
reliably predicted from the ELF file itself. I guess we're already
discussing this in #80 #80—
Reply to this email directly or view it on GitHub
#79 (comment).Saludos,
Felipe Sateler—
Reply to this email directly or view it on GitHub
#79 (comment).
Michael
from patchelf.
See #216
from patchelf.
Related Issues (20)
- SEGV when ELF has a malformed .dynamic section
- Relocatable binaries not handled
- Patchelf 0.18.0 Build failure on s390x with "span : out of range error"
- build failed for NetBSD
- rename-dynamic-symbols produces unusable binary
- Need help for cross-compliling libc.so.6 HOT 1
- patchelf: cannot normalize PT_NOTE segment: non-contiguous SHT_NOTE sections HOT 1
- _arguments:463: command not found: dynamic HOT 6
- `replace-needed.sh` test fails on 32-bit arm
- [RISCV] Error on 'make check' - relocation truncated to fit: R_RISCV_RVC_LUI against `__TMC_LIST__'
- Patching hard-coded paths within the text segment.
- Add a way to change visibility of symbols
- Version of gcc compiler effects correctness of patchelf 0.18 HOT 1
- Segfault with auditwheel and patchelf HOT 2
- Test shared-rpath fails when building with lld HOT 1
- adding an RPATH makes it impossible to extract the GNU Build ID from a core dump
- build-id.sh fails when `LANG` ≠ `C`
- autoPatchelfHook and separateDebugInfo interact poorly HOT 1
- FAIL: shared-rpath.sh
- The utility sets RUNPATH instead of RPATH
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from patchelf.