Re: [Elftoolchain-developers] Remaining FreeBSD ELF Tool Chain changes in the queue

[Joseph K. <jk...@us...>]

Ed,

First, thank you for stepping up to shepherd these
changes from FreeBSD into the Elftoolchain sources.

I can confirm that I was able to build and
successfully run the test suites at Elftoolchain/r3769
on NetBSD 8/i386 and Ubuntu 18.04.

The Elftoolchain tree currently fails to compile
on NetBSD 7.1.2/i386 and OpenBSD 6.3/amd64,
but these failures seem unrelated to the current
changes. I haven't checked the other platforms,
namely DragonFlyBSD, Minix, other combinations of
BSD OS versions and architectures yet.

A few comments below:

> libelf: reload section headers after update with ELF_C_WRITE
> https://reviews.freebsd.org/D10486

I would like to understand what the actual problem is
before folding in this patch. A small test program
(or a pointer to existing source that needs this
change to work correctly) would be helpful.

Specifically, I would like confirm that a program
that uses the ELF(3) API correctly would need this
patch. It may be that our documentation about
the state of an Elf descriptor after a call to
elf_update(3) may need to be improved.

> libelf: Use a red-black tree to manage the section list
> https://reviews.freebsd.org/D20443

Two questions here:

1. Per the FreeBSD Phabricator entry the motivation
   for this change was to speed up elf_getscn(3).
   If that is the case, how many sections does the
   ELF object need to have before the use of a RB tree
   vs a simpler data structure become relevant? I'm
   curious if performance measurements were done?

2. The other thing to check would be whether our
   target platforms have <sys/tree.h> implementations
   suitable for use from userland.

Regards,
Joseph Koshy