Re: none

[Dodji Seketeli <dodji@seketeli.org>]

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