Dear Mark,
Mark Wielaard wrote on 08.08.2015 00:35:
On Thu, Aug 06, 2015 at 05:14:25PM +0200, Kai Wasserbäch wrote:
Could you compile the following with:
gcc -g -lelf -o elfrel elfrel.c
this does not work for several reasons:
1. I certainly need -std=c99 for the inline initialisation of the
On Sat, Aug 08, 2015 at 10:58:15AM +0200, Kai Wasserbäch wrote:
And there *IS* a difference vs. your output: for you the relocations in
794488_elfs/libelf1/dump.elf.J4EnbO look fine, for me the second relocation is
botched with libelf1 while it works with libelfg0.
libelf1:
relocations: 2
On Sat, Aug 08, 2015 at 11:47:04AM +0200, Mark Wielaard wrote:
On Sat, Aug 08, 2015 at 10:58:15AM +0200, Kai Wasserbäch wrote:
And there *IS* a difference vs. your output: for you the relocations in
794488_elfs/libelf1/dump.elf.J4EnbO look fine, for me the second relocation
is
botched
tag 794488 = patch
thanks
Kurt Roeckx wrote on 08.08.2015 12:06:
On Sat, Aug 08, 2015 at 11:47:04AM +0200, Mark Wielaard wrote:
On Sat, Aug 08, 2015 at 10:58:15AM +0200, Kai Wasserbäch wrote:
And there *IS* a difference vs. your output: for you the relocations in
On Sat, Aug 08, 2015 at 12:31:54PM +0200, Kai Wasserbäch wrote:
https://sources.debian.net/src/elfutils/0.163-4/debian/patches/0003-Add-mips-n64-relocation-format-hack.patch/?hl=34#L34
Note how that replaces the cast and sizeof Elf64_Rel with Elf64_Rela
in the memcpy. Those are not the
On Thu, Aug 06, 2015 at 05:14:25PM +0200, Kai Wasserbäch wrote:
Could you compile the following with:
gcc -g -lelf -o elfrel elfrel.c
this does not work for several reasons:
1. I certainly need -std=c99 for the inline initialisation of the
counter in the for() statement.
Ah, yes, this
Dear Mark,
Mark Wielaard wrote on 06.08.2015 00:29:
On Wed, 2015-08-05 at 17:55 +0200, Kai Wasserbäch wrote:
So, if I've understood you correctly, you want an ELF dump of a Mesa build
linked against libelfg0 and one linked against libelf1. You can find the
generated files in the attached Tar
On Wed, 2015-08-05 at 11:13 +0900, Michel Dänzer wrote:
Note that the ELF object is actually created in LLVM.
Do you happen to know whether that also uses libelf to generate the
file? I am assuming there is some bug in the relocation section parsing
and that the generated ELF images are
On 05.08.2015 18:55, Mark Wielaard wrote:
On Wed, 2015-08-05 at 11:13 +0900, Michel Dänzer wrote:
Note that the ELF object is actually created in LLVM.
Do you happen to know whether that also uses libelf to generate the
file?
AFAICT LLVM doesn't use libelf, presumably it has its own ELF
Michel Dänzer wrote on 05.08.2015 12:08:
On 05.08.2015 18:55, Mark Wielaard wrote:
On Wed, 2015-08-05 at 11:13 +0900, Michel Dänzer wrote:
Note that the ELF object is actually created in LLVM.
Do you happen to know whether that also uses libelf to generate the
file?
AFAICT LLVM doesn't
On Wed, 2015-08-05 at 17:55 +0200, Kai Wasserbäch wrote:
So, if I've understood you correctly, you want an ELF dump of a Mesa build
linked against libelfg0 and one linked against libelf1. You can find the
generated files in the attached Tar archive. Please note, that the run with
libelf1 only
On 04.08.2015 05:34, Kai Wasserbäch wrote:
Dear Mark,
Mark Wielaard wrote on 03.08.2015 21:47:
Could you point me to the source code that does the libelf calls to create
the ELF file? Maybe reading the source helps to figure out what might go
wrong. The stacktrace from the test doesn't
Mark Wielaard wrote on 04.08.2015 00:17:
On Mon, Aug 03, 2015 at 10:34:19PM +0200, Kai Wasserbäch wrote:
Could you point me to the source code that does the libelf calls to create
the ELF file? Maybe reading the source helps to figure out what might go
wrong. The stacktrace from the test
On Tue, Aug 04, 2015 at 07:26:19PM +0200, Kai Wasserbäch wrote:
Thanks that was really helpful. It looks like the real problem is the
parsing of the relocation section. Would it be possible for you to dump
the ELF image that is being parsed in radeon/radeon_elf_util.c
(radeon_elf_read)
Package: libelf1
Version: 0.163-4
Severity: normal
Tags: upstream
Hi,
when I link my Mesa build against libelf1, some Piglit [0] tests start
throwing SIGSEGVs. Two of those tests are
spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst,src}.
When I link Mesa (or more specifically my
On Mon, Aug 03, 2015 at 10:34:19PM +0200, Kai Wasserbäch wrote:
Could you point me to the source code that does the libelf calls to create
the ELF file? Maybe reading the source helps to figure out what might go
wrong. The stacktrace from the test doesn't immediately seem to give a
direct
Mark Wielaard wrote on 03.08.2015 20:06:
On Mon, Aug 03, 2015 at 05:44:01PM +0200, Kai Wasserbäch wrote:
when I link my Mesa build against libelf1, some Piglit [0] tests start
throwing SIGSEGVs. Two of those tests are
spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst,src}.
When
On Mon, Aug 03, 2015 at 05:44:01PM +0200, Kai Wasserbäch wrote:
when I link my Mesa build against libelf1, some Piglit [0] tests start
throwing SIGSEGVs. Two of those tests are
spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst,src}.
When I link Mesa (or more specifically my
On Mon, Aug 03, 2015 at 08:31:12PM +0200, Kai Wasserbäch wrote:
Steps to reproduce:
This is going to be a bit hard for me to reproduce since I don't
actually use Debian for development (sorry). I do work on upstream
elfutils though.
- you need a AMD GPU powered by the radeonsi driver
I don't
Dear Mark,
Mark Wielaard wrote on 03.08.2015 21:47:
On Mon, Aug 03, 2015 at 08:31:12PM +0200, Kai Wasserbäch wrote:
Steps to reproduce:
This is going to be a bit hard for me to reproduce since I don't
actually use Debian for development (sorry). I do work on upstream
elfutils though.
-
20 matches
Mail list logo
