Re: The elfutils-devel mailinglist is now at sourceware.

[Kurt Roeckx]

On Fri, Dec 30, 2016 at 10:25:42PM +0100, Mark Wielaard wrote:
> Hi elfutils hackers,
> 
> The elfutils-devel mailinglist is now hosted at sourceware.
> https://sourceware.org/ml/elfutils-devel/
> 
> Everybody subscribed to the old elfutils-devel hosted at
> lists.fedorahosted.org has been subscribed to the new list.

This list doesn't has a List-Id, can this be fixed?

The headers show:
Mailing-List: contact elfutils-devel-h...@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 

While the old one has:
Precedence: list
List-Id: List for developers of elfutils 
Archived-At: 

List-Archive: 

List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 

As far as I know, the List-Id is what you really want.


Kurt

Re: elfutils 0.175 released

[Kurt Roeckx]

On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> ELFUTILS 0.175 - http://elfutils.org/
> 
> A new release of elfutils is available at:
> ftp://sourceware.org/pub/elfutils/0.175/
> or https://sourceware.org/elfutils/ftp/0.175/

Trying to build this on Debian, I get 8 failures, but they all
seem to be white space differences. I've attached the
test-suite.log file.


Kurt

==
   elfutils 0.175: tests/test-suite.log
==

# TOTAL: 204
# PASS:  195
# SKIP:  1
# XFAIL: 0
# FAIL:  8
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-readelf-const-values.sh
=

--- readelf.out 2018-11-18 23:43:41.610890094 +0100
+++ -   2018-11-18 23:43:41.616503487 +0100
@@ -21,7 +21,7 @@
  low_pc   (addr) 0x004004d0
  high_pc  (data8) 3 (0x004004d3)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  call_all_calls   (flag_present) yes
  sibling  (ref4) [5e]
  [4d]  variable abbrev: 1
@@ -59,7 +59,7 @@
  low_pc   (addr) 0x004003e0
  high_pc  (data8) 7 (0x004003e7)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  GNU_all_call_sites   (flag_present) yes
  sibling  (ref4) [   119]
  [b0]  variable abbrev: 3
FAIL run-readelf-const-values.sh (exit status: 1)

FAIL: run-readelf-twofiles.sh
=

--- readelf.out 2018-11-18 23:43:44.286830882 +0100
+++ -   2018-11-18 23:43:44.295663903 +0100
@@ -8,15 +8,15 @@
  [ 0] range 34, 35
   0x0040049c ..
   0x0040049c 
-   [   0] breg7 -8
+   [ 0] breg7 -8
   range 35, 46
   0x0040049d ..
   0x004004ad 
-   [   0] breg7 0
+   [ 0] breg7 0
   range 46, 47
   0x004004ae ..
   0x004004ae 
-   [   0] breg7 -8
+   [ 0] breg7 -8
 
 testfile14:
 
@@ -27,12 +27,12 @@
  [ 0] range 34, 35
   0x0040049c ..
   0x0040049c 
-   [   0] breg7 -8
+   [ 0] breg7 -8
   range 35, 46
   0x0040049d ..
   0x004004ad 
-   [   0] breg7 0
+   [ 0] breg7 0
   range 46, 47
   0x004004ae ..
   0x004004ae 
-   [   0] breg7 -8
+   [ 0] breg7 -8
FAIL run-readelf-twofiles.sh (exit status: 1)

FAIL: run-readelf-loc.sh


--- readelf.out 2018-11-18 23:43:44.446827342 +0100
+++ -   2018-11-18 23:43:44.458498779 +0100
@@ -5,17 +5,17 @@
  [ 0] range 0, d
   0x00400480 ..
   0x0040048c 
-   [   0] reg5
+   [ 0] reg5
  [23] range 5, d
   0x00400485 ..
   0x0040048c 
-   [   0] reg5
+   [ 0] reg5
 
  CU [e0] base: 0x004004a0 
  [46] range 12, 1a
   0x004004b2 ..
   0x004004b9 
-   [   0] breg5 0
+   [ 0] breg5 0
 
 DWARF section [34] '.debug_ranges' at offset 0xd94:
 
FAIL run-readelf-loc.sh (exit status: 1)

FAIL: run-readelf-variant.sh


--- testfile2.temp  2018-11-18 23:43:51.70686 +0100
+++ -   2018-11-18 23:43:51.714817340 +0100
@@ -1,7 +1,7 @@
  byte_size(exprloc) 
-  [   0] push_object_address
-  [   1] deref_size 1
+  [ 0] push_object_address
+  [ 1] deref_size 1
   [ 3] call4 [95]
-  [   8] plus_uconst 7
-  [  10] const1s -4
-  [  12] and
+  [ 8] plus_uconst 7
+  [10] const1s -4
+  [12] and
FAIL run-readelf-variant.sh (exit status: 1)

FAIL: run-readelf-types.sh
==

--- readelf.out 2018-11-18 23:43:56.682556562 +0100
+++ -   2018-11-18 23:43:56.694717935 +0100
@@ -19,7 +19,7 @@
  low_pc   (addr) 0x004005b0 
  high_pc  (data8) 11 (0x004005bb)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  GNU_all_call_sites   (flag_present) yes
  [46]base_typeabbrev: 10
  byte_size(data1) 4
FAIL run-readelf-types.sh (exit status: 1)

FAIL: run-readelf-dwz-multi.sh
==

--- readelf.out 2018-11-18 23:43:56.790554172 +0100
+++ -   2018-11-18 23:43:56.801299743 +0100
@@ -26,7 +26,7 @@
  low_pc   (addr) 0x004006ac 
  high_pc

Re: elfutils 0.175 released

[Kurt Roeckx]

On Mon, Nov 19, 2018 at 07:53:07AM +0100, Mark Wielaard wrote:
> On Sun, Nov 18, 2018 at 11:46:29PM +0100, Kurt Roeckx wrote:
> > On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> > > ELFUTILS 0.175 - http://elfutils.org/
> > > 
> > > A new release of elfutils is available at:
> > > ftp://sourceware.org/pub/elfutils/0.175/
> > > or https://sourceware.org/elfutils/ftp/0.175/
> > 
> > Trying to build this on Debian, I get 8 failures, but they all
> > seem to be white space differences. I've attached the
> > test-suite.log file.
> 
> That looks like you somehow are missing:
> 
> commit 704f5fc477efaf120980449e677deb563da8491f
> Author: Mark Wielaard 
> Date:   Wed Nov 29 15:43:26 2017 +0100
> 
> readelf: Adjust print_ops formatting.
> 
> Use only 2 spaces for index (there are never 1, the most seen in the
> wild is 64). Adjust re-indenting after GNU_entry_value.
> 
> Signed-off-by: Mark Wielaard 
> 
> But that is a commit from elfutils-0.171.
> Maybe you have a local patch that conflicts with it?

I somehow ended up with something that reverts it, no idea why.
After removing that everything seems to work.


Kurt

Re: elfutils 0.175 released

[Kurt Roeckx]

On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> ELFUTILS 0.175 - http://elfutils.org/
> 
> A new release of elfutils is available at:
> ftp://sourceware.org/pub/elfutils/0.175/
> or https://sourceware.org/elfutils/ftp/0.175/

I'm gettings errors on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=riscv64&ver=0.175-1&stamp=1542669684&raw=0


Kurt

Re: RISC-V support

[Kurt Roeckx]

On Tue, Jan 08, 2019 at 02:52:33PM +0100, Mark Wielaard wrote:
> > There is a problem here though.  The riscv support was written to try
> > to handle both 32-bit and 64-bit targets with a single elfutils
> > backend.  But I have 6 ABIs I need to (theoretically) handle in
> > riscv_retval.c.  The return_value_location function doesn't take any
> > ebl or elf pointer, so I can't handle it there.  I can handle it in
> > riscv_init.c by checking ebl and elf pointers there, and calling an
> > appropriate function, but I'm not sure if that is OK.  Currently,
> > none
> > of the *_init.c files are using the elf pointer argument.
> 
> The ppc64 init does (to lookup the odp table which is necessary for
> ppc64[be], but not ppc64le). It is allowed. And the backends/ebl
> interface is completely internal, so feel free to suggest changes if
> they make sense for riscv. If it is necessary we'll just update the
> other backends.

I've been looking at mips, and it seems to have many different
ABIs too. A patch I've received does this:
int
mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op **locp)
{
  /* First find the ABI used by the elf object */
  enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf);

The patch only supports 6 ABIs, but I think there are really over
10 ABIs.

Maybe it would be good that we only need to determine the ABI
once, instead of each time the function is called.


Kurt

Re: RISC-V support

[Kurt Roeckx]

On Sat, Jan 12, 2019 at 11:35:48PM +0100, Mark Wielaard wrote:
> On Sat, 2019-01-12 at 00:23 +0100, Kurt Roeckx wrote:
> > I've been looking at mips, and it seems to have many different
> > ABIs too. A patch I've received does this:
> > int
> > mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op
> > **locp)
> > {
> >   /* First find the ABI used by the elf object */
> >   enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf);
> > 
> > The patch only supports 6 ABIs, but I think there are really over
> > 10 ABIs.
> 
> But how many are actually used? Which does Debian support?

I'm not at all an export of mips, I really don't know that much
about it.

We have 3 mips ports, but mips and mipsel are the same ABI, it's
just big endian vs little endian. But as far as I understand it,
we transitioned those 2 ports from one ABI to an other, so they
are compatible with yet an other ABI. I think that at least makes
4 ABIs we care about. And I think gcc supports many different ones
depending on compiler flags you give to it, but I really don't know.


Kurt

Re: RISC-V support

[Kurt Roeckx]

On Sat, Jan 12, 2019 at 05:06:18PM -0800, Jim Wilson wrote:
> On Sat, Jan 12, 2019 at 3:21 PM Kurt Roeckx  wrote:
> > > But how many are actually used? Which does Debian support?
> >
> > I'm not at all an export of mips, I really don't know that much
> > about it.
> 
> It depends on how you count ABIs, but yes there have unfortunately
> been a lot of them over the years.
> 
> As a practical matter, you should only need support for the (old) 32
> bit ABI with pic support, the n32 ABI (which is 32-bit types on a
> 64-bit machine like the x86_64 x32 ABI), and the (new) 64-bit ABI.
> Those are the only ones that gcc supports for linux and other POSIX
> operating systems.  These exist in both big-endian and little-endian
> forms.

O32 really has at least the following variants:
- O32 FP32
- O32 FPXX
- O32 FP64
- O32 FP64A

They are all different ABIs related to the floating points. It's my
understanding that Debian's mips and mipsel port was O32 FP32 and is now
using O32 FPXX, and that mips64el is using N64.


Kurt

Elfutils 0.176 and riscv

[Kurt Roeckx]

On Debian's riscv64 port, this is a log of the build:
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=riscv64&ver=0.176-1&stamp=1550335976&raw=0

It failed with:
FAIL: run-backtrace-native.sh
=

0x200x219000/lib/riscv64-linux-gnu/ld-2.28.so
0x21a0000x21c000[vdso: 10935]
0x2220000x238000/lib/riscv64-linux-gnu/libpthread-2.28.so
0x23c0000x2000146000/lib/riscv64-linux-gnu/libc-2.28.so
0x2aa0000x2ae000/<>/tests/backtrace-child
TID 10935:
# 0 0x231278raise
TID 10938:
# 0 0x231278raise
/<>/tests/backtrace: dwfl_thread_getframes: No DWARF information 
found
/<>/tests/backtrace: dwfl_thread_getframes: No DWARF information 
found
backtrace: backtrace.c:81: callback_verify: Assertion `seen_main' failed.
./test-subr.sh: line 84: 10933 Aborted 
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" 
$VALGRIND_CMD "$@"
backtrace-child: no main
FAIL run-backtrace-native.sh (exit status: 1)

FAIL: run-backtrace-dwarf.sh


0x2a43c6raise
/<>/tests/backtrace-dwarf: dwfl_thread_getframes: No DWARF 
information found
dwarf: no main
FAIL run-backtrace-dwarf.sh (exit status: 1)

FAIL: run-backtrace-native-core.sh
==

0x21a0000x21b000linux-vdso.so.1
0x200x219158ld-linux-riscv64-lp64d.so.1
0x23c0000x2000149220libc.so.6
0x2220000x23b478libpthread.so.0
0x2aa0000x2ad0d8backtrace-child
TID 10994:
# 0 0x231278raise
TID 10992:
# 0 0x229e20__GI___pthread_timedjoin_ex
/<>/tests/backtrace: dwfl_thread_getframes: No DWARF information 
found
/<>/tests/backtrace: dwfl_thread_getframes: No DWARF information 
found
backtrace: backtrace.c:81: callback_verify: Assertion `seen_main' failed.
./test-subr.sh: line 84: 10998 Aborted 
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" 
$VALGRIND_CMD "$@"
backtrace-child-core.10992: no main
rmdir: failed to remove 'test-10977': Directory not empty
FAIL run-backtrace-native-core.sh (exit status: 1)



Kurt