Test fails due to lost content of LD_LIBRARY_PATH
by Serge Pavlov
Hi all,
Tests asm-tst4, asm-tst5 and asm-tst6 can fail if binaries produced by
compiler require shared libraries which are not in system directories. For
instance if the binaries are produced by development version of compiler.
In such cases LD_LIBRARY_PATH should contain path to non-standard location
of libraries, but in the aforementioned tests content of this variable is
lost.
The following patch can be used to solve the problem:
diff --git a/tests/asm-tst4.c b/tests/asm-tst4.c
index 54d054c..e6a6210 100644
--- a/tests/asm-tst4.c
+++ b/tests/asm-tst4.c
@@ -102,7 +102,8 @@ main (void)
if (result == 0)
result = WEXITSTATUS (system ("\
-env LD_LIBRARY_PATH=../libelf ../src/elflint -q asm-tst4-out.o"));
+env LD_LIBRARY_PATH=../libelf${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH\
+ ../src/elflint -q asm-tst4-out.o"));
/* We don't need the file anymore. */
unlink (fname);
diff --git a/tests/asm-tst5.c b/tests/asm-tst5.c
index 2a8b3f0..f81272b 100644
--- a/tests/asm-tst5.c
+++ b/tests/asm-tst5.c
@@ -114,7 +114,8 @@ main (void)
if (result == 0)
result = WEXITSTATUS (system ("\
-env LD_LIBRARY_PATH=../libelf ../src/elflint -q asm-tst5-out.o"));
+env LD_LIBRARY_PATH=../libelf${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH\
+ ../src/elflint -q asm-tst5-out.o"));
/* We don't need the file anymore. */
unlink (fname);
diff --git a/tests/asm-tst6.c b/tests/asm-tst6.c
index bd6a71d..a4f5ac8 100644
--- a/tests/asm-tst6.c
+++ b/tests/asm-tst6.c
@@ -148,7 +148,8 @@ main (void)
if (result == 0)
result = WEXITSTATUS (system ("\
-env LD_LIBRARY_PATH=../libelf ../src/elflint -q asm-tst6-out.o"));
+env LD_LIBRARY_PATH=../libelf${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH\
+ ../src/elflint -q asm-tst6-out.o"));
/* We don't need the file anymore. */
unlink (fname);
Thanks,
--Serge
11 years, 10 months
Using libelf for modify files
by Tsyvarev Andrey
Hi all,
I try to use libelf for modify Linux kernel modules (for
instrumentation purposes).
When only some bytes in ELF sections' data are changed, everything
works.
When new data blocks are appended to some sections, everything works
provided that previous blocks has been read (using elf_getdata()).
Otherwise previouse section's content are zeroed or even entire
section disappears.
When try to append new section to the file, either error about
insufficient memory occures at update (elf_update()) stage, or no error
generated, but section is not added.
Attached simple program demonstrates another behaviour, when section
with garbage in its header is added. Valgrind shows that library calls
pwrite() with buffer contained some unaddressable bytes.
I even try to manually mark different ELF elements as dirty (using
elf_flag*()), but nothing is changed.
Does the example is wrong? Or library contains errors in implementation?
--
With regards,
Andrey Tsyvarev mailto:tsyvarev@ispras.ru
11 years, 11 months
Cannot build trunk version
by Serge Pavlov
Hi,
I cloned repository and invoked commands:
autoheader
aclocal -I m4
autoconf
automake -a -c
./configure
make
but eventuallyI get an error:
make[2]: Entering directory `/export/users/svpavlov/repo/elfutils/libcpu'
m4 -Di386 -DDISASSEMBLER defs/i386 > i386_defs
sed
'1,/^%%/d;/^#/d;/^[[:space:]]*$/d;s/[^:]*:\([^[:space:]]*\).*/MNE(\1)/;s/{[^}]*}//g;/INVALID/d'
\
i386_defs | sort -u > i386.mnemonics
make[2]: *** No rule to make target `i386_dis.h', needed by
`i386_disasm.o'. Stop.
What's wrong?
Thanks,
--Serge
11 years, 11 months
Bugfix for eu-readelf --exception elf32-binary
by Karel Klic
Hello,
the attached tiny patch fixes the output of `eu-readelf --exception /path/to/binary` for 32-bit stripped binaries. Both elfutils-0.152 and recent git are affected, AFAICT.
Reproducer:
$ eu-readelf --exception zyGrib-3.9.9-3.fc16.i686/usr/bin/zyGrib
...
Call frame information section [17] '.eh_frame' at offset 0x109440:
[ 0] CIE length=20
...
[ 18] FDE length=16 cie=[ 0]
...
[ 2c] CIE length=28
CIE_id: 0
version: 1
augmentation: "zPLR"
code_alignment_factor: 1
data_alignment_factor: -4
return_address_register: 8
Augmentation data: 0 eu-readelf: invalid encoding
<end of output>
What happens (all functions are in readelf.c):
1. In function print_debug, the 'dwfl_module_getdwarf (dwflmod, &dwbias)' call returns NULL as the binary is stripped, so 'dummy_dbg' from the same function is assigned to 'dbg' variable.
Dwarf dummy_dbg = { .other_byte_order = MY_ELFDATA != ehdr->e_ident[EI_DATA] };
dbg = &dummy_dbg;
2. Later, when reading the .eh_frame contents in function print_debug_frame_section, read_encoded is called.
3. The parameter encoding of read_encoded represents DW_EH_PE_absptr.
4. read_encoded: gelf_getclass (dbg->elf) is called.
5. read_encoded: dbg->elf is NULL, because elf member is not being assigned for 'dummy_dbg'.
6. read_encoded: So gelf_getclass (NULL) returns ELFCLASSNONE
7. read_encoded: "encoding = gelf_getclass (dbg->elf) == ELFCLASS32 ? DW_EH_PE_udata4 : DW_EH_PE_udata8" is evaluated to DW_EH_PE_udata8.
8. read_encoded: Reading of udata8 fails, because this is 32-bit ELF, so there is only udata4 in the binary.
Karel
11 years, 11 months
question on ebl openbackend dlopen()
by Tony Jones
Hi.
Can anyone tell me how the dlopen() calls work on a Fedora system if a
static libdw is used?
On SuSE systems, if libdw.so is used (containing relevant libebl) I see
the first dlopen("$ORIGIN/../$LIB/elfutils/libebl_x86_64.so" succeed as:
open("/usr/lib64/../lib64/elfutils/libebl_x86_64.so", O_RDONLY) = 8
If the code is statically linked against libdw.a the first dlopen
attempts to generate a path
"/{path_to_static_exe}/../lib64/elfutils/libebl_x86_64.so" which fails.
The second basename dlopen() attempts a path search but this never looks
in the "elfutils" subfolder.
Tony
11 years, 11 months
Error in elf_from_remote_memory?
by Serge Pavlov
Hi,
In function 'elf_from_remote_memory' (file elf_from_memory.c) I see
references to 32-bit variant when file format is 64-bit one in couple of
places:
line 246:
case ELFCLASS64:
if (elf32_xlatetom (&xlateto, &xlatefrom,
ehdr.e32.e_ident[EI_DATA]) == NULL)
goto libelf_error;
for (uint_fast16_t i = 0; i < phnum; ++i)
if (phdrs.p32[i].p_type == PT_LOAD) //<===== should it be phdrs.p64[i] ?
and line 323:
case ELFCLASS64:
for (uint_fast16_t i = 0; i < phnum; ++i)
if (phdrs.p32[i].p_type == PT_LOAD) //<===== should it be phdrs.p64[i] ?
Is it intentionally?
Thanks,
--Serge
12 years