(no subject)

[Mark Wielaard]

Hi,

There is now a libabigail riscv ci and try builder on
builder.sourceware.org. Most things seem to just work as is.
Here are two patches to improve the riscv support.

[PATCH 1/2] Recognize EM_RISCV in e_machine_to_string

Adds support for generating a human readable string for EM_RISCV.
It includes configure support in case the system elf.h doesn't
contain the macro. But that is just for really old systems, glibc
2.24 added it.

Note that elfutils libdw provides dwelf_elf_e_machine_string which
does a similar thing.

[PATCH 2/2] Fix ABG_ASSERT in build_ir_node_from_die for DW_TAG_member

Fixes an assert that for some reason only shows up on riscv 
in runtesttypesstability against the DWARF for the test file:
test-types-stability/PR27165-libzmq.so.5.2.3

The issue is that the DIE [2113c8] being checked is in a CU that is 
C++, but the dwarf reader current translation unit [b] is a GIMPLE 
(lto) one, marked as C99.

I think this is because that first compile unit contains a variable
DIE [35dcf] that has an abstract origin [21492f] with specification
[2113c8] and type [211bf6] in the later C++ CU.

With this make check is all green on riscv.

Cheers,

Mark

[PATCH 1/2] Recognize EM_RISCV in e_machine_to_string

[Mark Wielaard]

Check that EM_RISCV is defined in elf.h and if it is then recognize
it in e_machine_to_string, producing "elf-riscv".

	* configure.ac: Defining HAVE_EM_RISCV_MACRO if EM_RISCV
	is defined in elf.h.
	* src/abg-dwarf-reader.cc (e_machine_to_string): Handle
	EM_RISCV if HAVE_EM_RISCV_MACRO is defined.

Signed-off-by: Mark Wielaard <mark@klomp.org>
---
 configure.ac           | 12 ++++++++++++
 src/abg-elf-helpers.cc |  5 +++++
 2 files changed, 17 insertions(+)

diff --git a/configure.ac b/configure.ac
index 65b738d8..788b5620 100644
--- a/configure.ac
+++ b/configure.ac
@@ -947,6 +947,18 @@ if test x$HAS_EM_TILEGX = xyes; then
             [Defined to 1 if elf.h has EM_TILEGX macro defined])
 fi
 
+HAS_EM_RISCV=no
+AC_CHECK_DECL([EM_RISCV],
+              [HAS_EM_RISCV=yes],
+              [HAS_EM_RISCV=no],
+              [[#include <elf.h>]])
+
+if test x$HAS_EM_RISCV = xyes; then
+  AC_DEFINE([HAVE_EM_RISCV_MACRO],
+                 1,
+            [Defined to 1 if elf.h has EM_RISCV macro defined])
+fi
+
 HAS_R_AARCH64_ABS64=no
 AC_CHECK_DECL([R_AARCH64_ABS64],
 	      [HAS_R_AARCH64_ABS64=yes],
diff --git a/src/abg-elf-helpers.cc b/src/abg-elf-helpers.cc
index e05dccdc..87feb905 100644
--- a/src/abg-elf-helpers.cc
+++ b/src/abg-elf-helpers.cc
@@ -287,6 +287,11 @@ e_machine_to_string(GElf_Half e_machine)
       return "elf-tilera-tilegx";
 #endif
 
+#ifdef HAVE_EM_RISCV_MACRO
+    case EM_RISCV:
+      return "elf-riscv";
+#endif
+
     case EM_NUM:
       return "elf-last-arch-number";
     case EM_ALPHA:
-- 
2.39.3

[PATCH 2/2] Fix ABG_ASSERT in build_ir_node_from_die for DW_TAG_member

[Mark Wielaard]

When the die is a member, it is the CU of the die that should not be
in the C language, not the dwarf reader current translation unit.

	* src/abg-dwarf-reader.cc (build_ir_node_from_die): ABG_ASSERT
	!rdr.die_is_in_c(), not rdr.cur_transl_unit().

Signed-off-by: Mark Wielaard <mark@klomp.org>
---
 src/abg-dwarf-reader.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc
index 15a35edf..70e37403 100644
--- a/src/abg-dwarf-reader.cc
+++ b/src/abg-dwarf-reader.cc
@@ -15822,7 +15822,7 @@ build_ir_node_from_die(reader&	rdr,
 	bool var_is_cloned = false;
 
 	if (tag == DW_TAG_member)
-	  ABG_ASSERT(!is_c_language(rdr.cur_transl_unit()->get_language()));
+	  ABG_ASSERT(!rdr.die_is_in_c(die));
 
 	if (die_die_attribute(die, DW_AT_specification, spec_die, false)
 	    || (var_is_cloned = die_die_attribute(die, DW_AT_abstract_origin,
-- 
2.39.3

Re: none

[Dodji Seketeli]

Hello,

Mark Wielaard <mark@klomp.org> a écrit:

> Hi,
>
> There is now a libabigail riscv ci and try builder on
> builder.sourceware.org. Most things seem to just work as is.

Whoah ...

> Here are two patches to improve the riscv support.

Thanks.

> [PATCH 1/2] Recognize EM_RISCV in e_machine_to_string
>
> Adds support for generating a human readable string for EM_RISCV.
> It includes configure support in case the system elf.h doesn't
> contain the macro. But that is just for really old systems, glibc
> 2.24 added it.
>
> Note that elfutils libdw provides dwelf_elf_e_machine_string which
> does a similar thing.

Oh, I see that elfutils has it since 0.177.  That's "new" :-).  We
should then make libabigail's e_machine_to_string use
dwelf_elf_e_machine_string and require using an elfutils version >= 0.177.  Now
that elfutils supports pkg-config, it should be easy to require an
elfutils version.  What do you think?

>
> [PATCH 2/2] Fix ABG_ASSERT in build_ir_node_from_die for DW_TAG_member
>
> Fixes an assert that for some reason only shows up on riscv 
> in runtesttypesstability against the DWARF for the test file:
> test-types-stability/PR27165-libzmq.so.5.2.3
>
> The issue is that the DIE [2113c8] being checked is in a CU that is 
> C++, but the dwarf reader current translation unit [b] is a GIMPLE 
> (lto) one, marked as C99.

Oh, I see. Good catch.
>
> I think this is because that first compile unit contains a variable
> DIE [35dcf] that has an abstract origin [21492f] with specification
> [2113c8] and type [211bf6] in the later C++ CU.

Right.

> With this make check is all green on riscv.

Many thanks for this.

I am applying this patch first, then EM_RISCV one second.  That way, the
build stays green from the first patch.

Many thanks!

Cheers,

-- 
		Dodji

Re: Some libabigail RISC-V support issues

[Mark Wielaard]

Hi Dodji,

On Mon, Jan 08, 2024 at 04:13:39PM +0100, Dodji Seketeli wrote:
> Mark Wielaard <mark@klomp.org> a écrit:
> > [PATCH 1/2] Recognize EM_RISCV in e_machine_to_string
> >
> > Adds support for generating a human readable string for EM_RISCV.
> > It includes configure support in case the system elf.h doesn't
> > contain the macro. But that is just for really old systems, glibc
> > 2.24 added it.
> >
> > Note that elfutils libdw provides dwelf_elf_e_machine_string which
> > does a similar thing.
> 
> Oh, I see that elfutils has it since 0.177.  That's "new" :-).  We
> should then make libabigail's e_machine_to_string use
> dwelf_elf_e_machine_string and require using an elfutils version >= 0.177.  Now
> that elfutils supports pkg-config, it should be easy to require an
> elfutils version.  What do you think?

elfutils 0.177 was released in 2019 so should generally be availble.
It seems a good idea to use dwelf_elf_e_machine_string, but it
produces different descriptions. So it depends on if something depends
on it. If it is just a human readable description then I think the
strings from dwelf_elf_e_machine_string are nicer/more descriptive.

> > [PATCH 2/2] Fix ABG_ASSERT in build_ir_node_from_die for DW_TAG_member
> >
> > Fixes an assert that for some reason only shows up on riscv 
> > in runtesttypesstability against the DWARF for the test file:
> > test-types-stability/PR27165-libzmq.so.5.2.3
> >
> > The issue is that the DIE [2113c8] being checked is in a CU that is 
> > C++, but the dwarf reader current translation unit [b] is a GIMPLE 
> > (lto) one, marked as C99.
> 
> Oh, I see. Good catch.
> >
> > I think this is because that first compile unit contains a variable
> > DIE [35dcf] that has an abstract origin [21492f] with specification
> > [2113c8] and type [211bf6] in the later C++ CU.
> 
> Right.
> 
> > With this make check is all green on riscv.
> 
> Many thanks for this.
> 
> I am applying this patch first, then EM_RISCV one second.  That way, the
> build stays green from the first patch.

And it is green! \o/
https://builder.sourceware.org/buildbot/#/builders/libabigail-ubuntu-riscv

Cheers,

Mark