elftoolchain-developers — Discussion on elftoolchain development.

[Elftoolchain-developers] Fwd: svn commit: r352875 - head/contrib/elftoolchain/elfcopy

[Ed M. <em...@fr...>]

An elfcopy fix from FreeBSD:

---------- Forwarded message ---------
From: Aleksandr Rybalko <ra...@fr...>
Date: Sun, 29 Sep 2019 at 18:34
Subject: svn commit: r352875 - head/contrib/elftoolchain/elfcopy
To: <src...@fr...>, <svn...@fr...>,
<svn...@fr...>


Author: ray
Date: Sun Sep 29 22:34:01 2019
New Revision: 352875
URL: https://svnweb.freebsd.org/changeset/base/352875

Log:
  Put sections into expected offset in binary format.
  Calculate binary file offset using address field, because software
know only offset to known data, not where to load segment.
  With that patch, kernel .data section can have any alignment/offset
- kernel boot fine.

  PR:           235391
  Reviewed by:  markj
  MFC after:    1 month
  Differential Revision: https://reviews.freebsd.org/D21827

Modified:
  head/contrib/elftoolchain/elfcopy/binary.c

Modified: head/contrib/elftoolchain/elfcopy/binary.c
==============================================================================
--- head/contrib/elftoolchain/elfcopy/binary.c  Sun Sep 29 20:44:13
2019        (r352874)
+++ head/contrib/elftoolchain/elfcopy/binary.c  Sun Sep 29 22:34:01
2019        (r352875)
@@ -49,22 +49,23 @@ create_binary(int ifd, int ofd)
        Elf *e;
        Elf_Scn *scn;
        Elf_Data *d;
+       Elf64_Addr baseaddr;
        GElf_Shdr sh;
-       off_t base, off;
+       off_t baseoff, off;
        int elferr;

        if ((e = elf_begin(ifd, ELF_C_READ, NULL)) == NULL)
                errx(EXIT_FAILURE, "elf_begin() failed: %s",
                    elf_errmsg(-1));

-       base = 0;
-       if (lseek(ofd, base, SEEK_SET) < 0)
+       baseoff = 0;
+       if (lseek(ofd, baseoff, SEEK_SET) < 0)
                err(EXIT_FAILURE, "lseek failed");

        /*
         * Find base offset in the first iteration.
         */
-       base = -1;
+       baseoff = -1;
        scn = NULL;
        while ((scn = elf_nextscn(e, scn)) != NULL) {
                if (gelf_getshdr(scn, &sh) == NULL) {
@@ -76,14 +77,16 @@ create_binary(int ifd, int ofd)
                    sh.sh_type == SHT_NOBITS ||
                    sh.sh_size == 0)
                        continue;
-               if (base == -1 || (off_t) sh.sh_offset < base)
-                       base = sh.sh_offset;
+               if (baseoff == -1 || (off_t) sh.sh_offset < baseoff) {
+                       baseoff = sh.sh_offset;
+                       baseaddr = sh.sh_addr;
+               }
        }
        elferr = elf_errno();
        if (elferr != 0)
                warnx("elf_nextscn failed: %s", elf_errmsg(elferr));

-       if (base == -1)
+       if (baseoff == -1)
                return;

        /*
@@ -110,8 +113,8 @@ create_binary(int ifd, int ofd)
                if (d->d_buf == NULL || d->d_size == 0)
                        continue;

-               /* lseek to section offset relative to `base'. */
-               off = sh.sh_offset - base;
+               /* lseek to section offset relative to `baseaddr'. */
+               off = sh.sh_addr - baseaddr;
                if (lseek(ofd, off, SEEK_SET) < 0)
                        err(EXIT_FAILURE, "lseek failed");

Re: [Elftoolchain-developers] [PATCH] elfcopy: Stop using optind.

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

On Tue, Jul 30, 2019 at 3:44 PM Mark Johnston <ma...@fr...> wrote:
> I noted that most of the other ELFToolchain utilities adjust argc and
> argv by optind immediately after the getopt loop: addr2line, ar,
> cxxfilt, elfdump, readelf, size, and strings.

Added in [r3780], thanks!

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] [PATCH] elfcopy: Stop using optind.

[Ed M. <em...@fr...>]

On Tue, 30 Jul 2019 at 04:09, Joseph Koshy via Elftoolchain-developers
<elf...@li...> wrote:
>
> The option handling code in elfcopy(1) seems
> patterned after the getopt(3) usage example in
> the POSIX standard:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html.

The author of that example may have chosen to use optind to
demonstrate its existence and use though. It doesn't much matter, but
I find the "discard processed options" form somewhat more clear.

Re: [Elftoolchain-developers] [PATCH] elfcopy: Stop using optind.

[Mark J. <ma...@fr...>]

On Tue, Jul 30, 2019 at 09:08:38AM +0100, Joseph Koshy wrote:
> Mark,
> 
> On Fri, Jul 26, 2019 at 9:36 PM Mark Johnston <ma...@fr...> wrote:
> >
> > This marginally simplifies the code.  Writing argc--; argv++; after the
> > option parsing loop is a common idiom anyway.
> 
> The option handling code in elfcopy(1) seems
> patterned after the getopt(3) usage example in
> the POSIX standard:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html.

I noted that most of the other ELFToolchain utilities adjust argc and
argv by optind immediately after the getopt loop: addr2line, ar,
cxxfilt, elfdump, readelf, size, and strings.

> I'm curious -- would there be a drawback to
> using 'optind' to index the argv[] array?

There is no drawback, it just seemed odd to me to use it.  (And for
Capsicum I will need to add some more uses.)  If you prefer to keep
the existing code I will adjust my patches accordingly.

Re: [Elftoolchain-developers] [PATCH] elfcopy: Stop using optind.

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

Mark,

On Fri, Jul 26, 2019 at 9:36 PM Mark Johnston <ma...@fr...> wrote:
>
> This marginally simplifies the code.  Writing argc--; argv++; after the
> option parsing loop is a common idiom anyway.

The option handling code in elfcopy(1) seems
patterned after the getopt(3) usage example in
the POSIX standard:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html.

I'm curious -- would there be a drawback to
using 'optind' to index the argv[] array?

Regards,
Joseph Koshy

[Elftoolchain-developers] patches for Capsicum support

[Mark J. <ma...@fr...>]

Hi,

Lately I have done some work in FreeBSD to run elftoolchain
utilities in capability mode.  This is part of Capsicum, a software
sandboxing framework in FreeBSD.  The work required relatively few
modifications to the existing code since the utilities do not interact
much with the system beyond opening and closing files.  elfcopy and ar
required more work, and in the process I wrote a handful of small
patches to clean up or refactor the code before doing anything related
to Capsicum.

My hope is to minimize the diffs between upstream ELFToolchain and the
copy in FreeBSD's base system.  I am wondering if there is any interest
here in those clean-up patches.  In particular, I don't want to spam the
list with patches that have no functional effect unless there is some
willingness to take them.

Thanks,
-Mark

Re: [Elftoolchain-developers] [PATCH] strip: Only allow one positional parameter with -o.

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

On Fri, Jul 26, 2019 at 9:36 PM Mark Johnston <ma...@fr...> wrote:
> It doesn't make sense to strip multiple files into a single output file.
> Moreover, this is compatible with GNU strip.

Added in [r3778] and [r3779], thanks!

Regards,
Joseph Koshy

[Elftoolchain-developers] [PATCH] strip: Only allow one positional parameter with -o.

[Mark J. <ma...@fr...>]

It doesn't make sense to strip multiple files into a single output file.
Moreover, this is compatible with GNU strip.
---
 contrib/elftoolchain/elfcopy/main.c  | 2 +-
 contrib/elftoolchain/elfcopy/strip.1 | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/contrib/elftoolchain/elfcopy/main.c b/contrib/elftoolchain/elfcopy/main.c
index 9794a723c364..777cf30f3adc 100644
--- a/contrib/elftoolchain/elfcopy/main.c
+++ b/contrib/elftoolchain/elfcopy/main.c
@@ -1168,7 +1168,7 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
 	    ((ecp->flags & DISCARD_LLABEL) == 0) &&
 	    lookup_symop_list(ecp, NULL, SYMOP_STRIP) == NULL)
 		ecp->strip = STRIP_ALL;
-	if (argc == 0)
+	if (argc == 0 || (outfile != NULL && argc > 1))
 		strip_usage();
 
 	for (i = 0; i < argc; i++)
diff --git a/contrib/elftoolchain/elfcopy/strip.1 b/contrib/elftoolchain/elfcopy/strip.1
index b1633a51693b..7f11896b186f 100644
--- a/contrib/elftoolchain/elfcopy/strip.1
+++ b/contrib/elftoolchain/elfcopy/strip.1
@@ -23,7 +23,7 @@
 .\"
 .\" $Id: strip.1 3642 2018-10-14 14:24:28Z jkoshy $
 .\"
-.Dd September 17, 2011
+.Dd July 26, 2019
 .Dt STRIP 1
 .Os
 .Sh NAME
@@ -67,6 +67,7 @@ Remove all content except that which would be used for debugging.
 Write the stripped object to file
 .Ar outputfile .
 The default behaviour is to modify objects in place.
+When this argument is used, only one input file may be specified.
 .It Fl p | Fl -preserve-dates
 Preserve the object's access and modification times.
 .It Fl s | Fl -strip-all
-- 
2.22.0

[Elftoolchain-developers] [PATCH] elfcopy: Stop using optind.

[Mark J. <ma...@fr...>]

This marginally simplifies the code.  Writing argc--; argv++; after the
option parsing loop is a common idiom anyway.
---
 contrib/elftoolchain/elfcopy/main.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/contrib/elftoolchain/elfcopy/main.c b/contrib/elftoolchain/elfcopy/main.c
index 919fbf193bc4..f9a6cb612fab 100644
--- a/contrib/elftoolchain/elfcopy/main.c
+++ b/contrib/elftoolchain/elfcopy/main.c
@@ -1016,14 +1016,16 @@ elfcopy_main(struct elfcopy *ecp, int argc, char **argv)
 			elfcopy_usage();
 		}
 	}
+	argc -= optind;
+	argv += optind;
 
-	if (optind == argc || optind + 2 < argc)
+	if (argc == 0 || argc > 2)
 		elfcopy_usage();
 
-	infile = argv[optind];
+	infile = argv[0];
 	outfile = NULL;
-	if (optind + 1 < argc)
-		outfile = argv[optind + 1];
+	if (argc > 1)
+		outfile = argv[1];
 
 	create_file(ecp, infile, outfile);
 }
@@ -1066,8 +1068,10 @@ mcs_main(struct elfcopy *ecp, int argc, char **argv)
 			mcs_usage();
 		}
 	}
+	argc -= optind;
+	argv += optind;
 
-	if (optind == argc)
+	if (argc == 0)
 		mcs_usage();
 
 	/* Must specify one operation at least. */
@@ -1104,7 +1108,7 @@ mcs_main(struct elfcopy *ecp, int argc, char **argv)
 		sac->string = string;
 	}
 
-	for (i = optind; i < argc; i++) {
+	for (i = 0; i < argc; i++) {
 		/* If only -p is specified, output to /dev/null */
 		if (print && !append && !compress && !delete)
 			create_file(ecp, argv[i], "/dev/null");
@@ -1179,16 +1183,18 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
 			strip_usage();
 		}
 	}
+	argc -= optind;
+	argv += optind;
 
 	if (ecp->strip == 0 &&
 	    ((ecp->flags & DISCARD_LOCAL) == 0) &&
 	    ((ecp->flags & DISCARD_LLABEL) == 0) &&
 	    lookup_symop_list(ecp, NULL, SYMOP_STRIP) == NULL)
 		ecp->strip = STRIP_ALL;
-	if (optind == argc)
+	if (argc == 0)
 		strip_usage();
 
-	for (i = optind; i < argc; i++)
+	for (i = 0; i < argc; i++)
 		create_file(ecp, argv[i], outfile);
 }
 
-- 
2.22.0

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

[Mark J. <ma...@fr...>]

On Sun, Jun 30, 2019 at 02:35:16PM +0100, Joseph Koshy wrote:
> Mark,
> 
> m.j> The context for that change is FreeBSD PR 234949
> m.j> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234949).
> m.j> It comes from a series of changes which reduces
> m.j> elftoolchain's strip runtime on an archive of
> m.j> Haskell libraries compiled with -ffunction-sections.
> 
> Thanks for providing the context; nice work on that PR.
> 
> m.j> I know that *BSD provides tree.h and libbsd has a
> m.j> tree.h as well; that seemed sufficient to me, but
> m.j> maybe I'm missing something?  It seemed reasonable
> m.j> to use tree.h given that elftoolchain already makes
> m.j> extensive use of queue.h.
> 
> We've seen incompatibilities between *BSD's
> <sys/queue.h> implementations; for example, OpenBSD
> 6.3's <sys/queue.h> lacked the STAILQ_* macros, and so
> we had to provide a local copy in "common/_elftc.h".
> 
> I hope <sys/tree.h> is more portable than
> <sys/queue.h>, but if not we could add local
> definitions to "common/_elftc.h" till the time the
> differences are reconciled upstream.

I'm fairly confident that all of the BSDs have roughly the same RB_*
macros in tree.h.  I can try compiling elftoolchain on each of them, but
you may be better set up to test that than me.

> Thanks again for tracking down this performance
> issue.  I have created a ticket (on myself)
> (https://sourceforge.net/p/elftoolchain/tickets/574/)
> to fold in this change.

Thanks.  The full set of changes needed to get parity with GNU strip is
in the PR; they are all now committed to FreeBSD.

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

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

Mark,

m.j> The context for that change is FreeBSD PR 234949
m.j> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234949).
m.j> It comes from a series of changes which reduces
m.j> elftoolchain's strip runtime on an archive of
m.j> Haskell libraries compiled with -ffunction-sections.

Thanks for providing the context; nice work on that PR.

m.j> I know that *BSD provides tree.h and libbsd has a
m.j> tree.h as well; that seemed sufficient to me, but
m.j> maybe I'm missing something?  It seemed reasonable
m.j> to use tree.h given that elftoolchain already makes
m.j> extensive use of queue.h.

We've seen incompatibilities between *BSD's
<sys/queue.h> implementations; for example, OpenBSD
6.3's <sys/queue.h> lacked the STAILQ_* macros, and so
we had to provide a local copy in "common/_elftc.h".

I hope <sys/tree.h> is more portable than
<sys/queue.h>, but if not we could add local
definitions to "common/_elftc.h" till the time the
differences are reconciled upstream.

Thanks again for tracking down this performance
issue.  I have created a ticket (on myself)
(https://sourceforge.net/p/elftoolchain/tickets/574/)
to fold in this change.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Tests currently broken on FreeBSD

[Ed M. <em...@fr...>]

On Sat, 29 Jun 2019 at 15:29, Joseph Koshy <jk...@us...> wrote:
>
> What are the version numbers of the Python and py-yaml packages on this system?

It will be whatever gets installed by "pkg install -y git py27-yaml".
In my branch I added a 'pkg info' upon failure to .cirrus.yml and I
see:

py27-yaml-5.1                  Python YAML parser
python27-2.7.15                Interpreted object-oriented programming language

I'll add a version of this to .cirrus.yml in the svn repo shortly to
help track down issues in the future.

python27-2.7.15                Interpreted object-oriented programming language

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

[Mark J. <ma...@fr...>]

On Sat, Jun 29, 2019 at 10:51:57PM +0100, Joseph Koshy via Elftoolchain-developers wrote:
> > libelf: Use a red-black tree to manage the section list
> > https://reviews.freebsd.org/D20443
> 
> Two questions here:

Hi Joseph,

> 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?

The context for that change is FreeBSD PR 234949
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234949).
It comes from a series of changes which reduces elftoolchain's strip
runtime on an archive of Haskell libraries compiled with
-ffunction-sections.

One of the test files is libHSCabal-2.4.0.1_p.a, which contains 220
objects.  Among them, the minimum number of sections is 26, the
maximum is 46125, and the median and average are 964 and 2085,
respectively.

Reverting just this change (use a red-black tree) increases the runtime
of strip from 4s to 80s for this file.

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

I know that *BSD provides tree.h and libbsd has a tree.h as well; that
seemed sufficient to me, but maybe I'm missing something?  It seemed
reasonable to use tree.h given that elftoolchain already makes extensive
use of queue.h.

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

Re: [Elftoolchain-developers] [elftoolchain-vcs-changes] SF.net SVN: elftoolchain:[3763] trunk/libelf/elf_update.c

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

Thanks for folding in work from the FreeBSD project.

A question about [r3763]:

> libelf: assert that msz is non-zero
>
> Reported by FreeBSD Coverity, CID 976023
>
> Obtained from FreeBSD r316685 by emaste.
>
> Modified Paths:
> --------------
>     trunk/libelf/elf_update.c

> /*
>   * Layout strategy:
> @@ -819,6 +819,7 @@
>   assert(d->d_buf != NULL);
>   assert(d->d_version == e->e_version);
>   assert(d->d_size % msz == 0);
> + assert(msz != 0);
>  
>   nobjects = (size_t) (d->d_size / msz);

The new assertion shouldn't be necessary since the
code a few lines up returns (-1) if 'msz' is zero.

Would this be a Coverity bug, or was FreeBSD's copy
of libelf not sync'ed to Elftoolchain -HEAD prior to
running Coverity's scanner?

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Tests currently broken on FreeBSD

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

> _E=`echo msb | tr '[a-z]' '[A-Z]'`; _C=`echo 32 | tr '[a-z]' '[A-Z]'`;
> cat /tmp/cirrus-ci-build/test/libelf/tset/common/check_elf.yaml | sed
> -e "s/ELFDATANONE/ELFDATA2${_E}/g" -e "s/ELFCLASSNONE/ELFCLASS${_C}/g"
> | /tmp/cirrus-ci-build/test/libelf/tset/bin/elfc -o check_elf.msb32
> /tmp/cirrus-ci-build/test/libelf/tset/bin/elfc:1610: YAMLLoadWarning:
> calling yaml.load() without Loader=... is deprecated, as the default
> Loader is unsafe. Please read https://msg.pyyaml.org/load for full
> details.
> elf = make_elf(yaml.load(stream))
> Usage: elfc [options] [input-file]
> elfc: error: cannot parse stream: could not determine a constructor
> for the tag '!Ehdr'
> in "<stdin>", line 4, column 7
> *** Error code 2

Thanks for the error report.

What are the version numbers of the Python and py-yaml packages on this system?

Regards,
Joseph Koshy

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

[Ed M. <em...@fr...>]

> libelf: fix .note conversion for non-native byte order ELF files
> https://reviews.freebsd.org/rS273443

In fact this was an incorrect change; I already merged the corrected
version in r3158.

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

[Ed M. <em...@fr...>]

On Fri, 28 Jun 2019 at 19:05, Ed Maste <em...@fr...> wrote:
>
> elfcopy: fix little-endian MIPS64 objects
> https://reviews.freebsd.org/D15734
> https://reviews.freebsd.org/rS344855
> https://reviews.freebsd.org/rS339083
> https://reviews.freebsd.org/rS339473

This is (part of) ELF Tool Chain ticket #559, although I notice now
that the FreeBSD commit did not address the /* TODO: Handle MIPS64
REL{,A} sections (ticket #559). */ in libelf_convert.m4, and in this
commit the conversion is done in gelf_rel.c/gelf_rela.c, not as a
translator.

> readelf: decode flag bits in DT_FLAGS/DT_FLAGS_1
> https://reviews.freebsd.org/D18784
> https://reviews.freebsd.org/rS343593
> https://reviews.freebsd.org/rS343665

Committed to ELF Tool Chain as r3765.

> readelf: decode FreeBSD note types
> https://reviews.freebsd.org/rS343669

Committed to ELF Tool Chain as r3766.

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

[Ed M. <em...@fr...>]

I have the changes listed below remaining in my queue to merging into
upstream ELF Tool Chain. After each commit headline I've included the
FreeBSD code review (if it has one) or the FreeBSD commit; in some
cases there are followup improvements to include in the change.

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

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

libelf: fix .note conversion for non-native byte order ELF files
https://reviews.freebsd.org/rS273443

libelf: remove 4-byte .note alignment for PowerPC
https://reviews.freebsd.org/rS273442

libdwarf: prepend DW_AT_comp_dir to relative line number dir entries
https://reviews.freebsd.org/D19705

elfcopy: copy raw (untranslated) contents to binary output
https://reviews.freebsd.org/rS327489

elfcopy: fix little-endian MIPS64 objects
https://reviews.freebsd.org/D15734
https://reviews.freebsd.org/rS344855
https://reviews.freebsd.org/rS339083
https://reviews.freebsd.org/rS339473

readelf: speed up readelf -wo
https://reviews.freebsd.org/D18843
https://reviews.freebsd.org/rS346327

readelf: decode flag bits in DT_FLAGS/DT_FLAGS_1
https://reviews.freebsd.org/D18784
https://reviews.freebsd.org/rS343593
https://reviews.freebsd.org/rS343665

readelf: decode FreeBSD note types
https://reviews.freebsd.org/rS343669

readelf: Add support for RISC-V specific e_flags
https://reviews.freebsd.org/rS349482

readelf: display NT_GNU_PROPERTY_TYPE_0 note name
https://reviews.freebsd.org/rS337569

Re: [Elftoolchain-developers] [PATCH 1/2] objtool: Rename elf_open to prevent conflict with libelf from elftoolchain

[Josh P. <jpo...@re...>]

On Thu, Jun 27, 2019 at 05:52:53PM -0700, Michael Forney wrote:
> On 2019-06-27, Josh Poimboeuf <jpo...@re...> wrote:
> > On Sun, Jun 16, 2019 at 04:14:59PM -0700, Michael Forney wrote:
> >> Signed-off-by: Michael Forney <mf...@mf...>
> >> ---
> >>  tools/objtool/check.c | 2 +-
> >>  tools/objtool/elf.c   | 2 +-
> >>  tools/objtool/elf.h   | 2 +-
> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > Sorry for the delay, I was out for a bit and I'm still trying to get
> > caught back up on email.
> 
> No worries :)
> 
> > These patches look fine.  I'll try to send them on to the -tip tree
> > shortly.
> 
> Thanks!
> 
> > Just curious, have you done much testing with the elftoolchain version
> > of libelf and objtool?  So far objtool has only been successfully used
> > with the elfutils version, so I'm just curious how compatible your
> > libelf is with the elfutils version.
> 
> I'm not affiliated with elftoolchain, I am just trying it out on my
> system as an alternative to elfutils libelf for its clean codebase
> that doesn't use many GNU C extensions.
> 
> I've done some basic testing to make sure that the .o files after
> being processed with `objtool generate --no-fp --retpoline` match
> between elfutils and elftoolchain. I noticed two differences, one of
> which was due to a bug in elftoolchain that has since been fixed, and
> the other is with the offset of SHT_NOBITS section after rewriting[0],
> which I think doesn't matter.

Awesome, that gives me a lot more confidence.  Thanks!

-- 
Josh

[Elftoolchain-developers] Tests currently broken on FreeBSD

[Ed M. <em...@fr...>]

In a recent Cirrus-CI build
(http://cirrus-ci.com/build/6213744988782592) the freebsd_11 task
failed with:

===> test/libelf/tset/common (all)
_E=`echo msb | tr '[a-z]' '[A-Z]'`; _C=`echo 32 | tr '[a-z]' '[A-Z]'`;
cat /tmp/cirrus-ci-build/test/libelf/tset/common/check_elf.yaml | sed
-e "s/ELFDATANONE/ELFDATA2${_E}/g" -e "s/ELFCLASSNONE/ELFCLASS${_C}/g"
| /tmp/cirrus-ci-build/test/libelf/tset/bin/elfc -o check_elf.msb32
/tmp/cirrus-ci-build/test/libelf/tset/bin/elfc:1610: YAMLLoadWarning:
calling yaml.load() without Loader=... is deprecated, as the default
Loader is unsafe. Please read https://msg.pyyaml.org/load for full
details.
elf = make_elf(yaml.load(stream))
Usage: elfc [options] [input-file]
elfc: error: cannot parse stream: could not determine a constructor
for the tag '!Ehdr'
in "<stdin>", line 4, column 7
*** Error code 2
Stop.

Re: [Elftoolchain-developers] [PATCH 1/2] objtool: Rename elf_open to prevent conflict with libelf from elftoolchain

[Michael F. <mf...@mf...>]

On 2019-06-27, Josh Poimboeuf <jpo...@re...> wrote:
> On Sun, Jun 16, 2019 at 04:14:59PM -0700, Michael Forney wrote:
>> Signed-off-by: Michael Forney <mf...@mf...>
>> ---
>>  tools/objtool/check.c | 2 +-
>>  tools/objtool/elf.c   | 2 +-
>>  tools/objtool/elf.h   | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> Sorry for the delay, I was out for a bit and I'm still trying to get
> caught back up on email.

No worries :)

> These patches look fine.  I'll try to send them on to the -tip tree
> shortly.

Thanks!

> Just curious, have you done much testing with the elftoolchain version
> of libelf and objtool?  So far objtool has only been successfully used
> with the elfutils version, so I'm just curious how compatible your
> libelf is with the elfutils version.

I'm not affiliated with elftoolchain, I am just trying it out on my
system as an alternative to elfutils libelf for its clean codebase
that doesn't use many GNU C extensions.

I've done some basic testing to make sure that the .o files after
being processed with `objtool generate --no-fp --retpoline` match
between elfutils and elftoolchain. I noticed two differences, one of
which was due to a bug in elftoolchain that has since been fixed, and
the other is with the offset of SHT_NOBITS section after rewriting[0],
which I think doesn't matter.

[0] https://sourceforge.net/p/elftoolchain/tickets/571/

Re: [Elftoolchain-developers] [PATCH 1/2] objtool: Rename elf_open to prevent conflict with libelf from elftoolchain

[Josh P. <jpo...@re...>]

On Sun, Jun 16, 2019 at 04:14:59PM -0700, Michael Forney wrote:
> Signed-off-by: Michael Forney <mf...@mf...>
> ---
>  tools/objtool/check.c | 2 +-
>  tools/objtool/elf.c   | 2 +-
>  tools/objtool/elf.h   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Sorry for the delay, I was out for a bit and I'm still trying to get
caught back up on email.

These patches look fine.  I'll try to send them on to the -tip tree
shortly.

Just curious, have you done much testing with the elftoolchain version
of libelf and objtool?  So far objtool has only been successfully used
with the elfutils version, so I'm just curious how compatible your
libelf is with the elfutils version.

-- 
Josh

[Elftoolchain-developers] [PATCH 2/2] objtool: Use Elf_Scn typedef instead of assuming tag name

[Michael F. <mf...@mf...>]

The libelf implementation might use a different tag name, and the
Elf_Scn typedef is already used throughout the rest of objtool.

Signed-off-by: Michael Forney <mf...@mf...>
---
 tools/objtool/elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 4116f564a0b0..a4258d80d4ce 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -463,7 +463,7 @@ struct section *elf_create_section(struct elf *elf, const char *name,
 {
 	struct section *sec, *shstrtab;
 	size_t size = entsize * nr;
-	struct Elf_Scn *s;
+	Elf_Scn *s;
 	Elf_Data *data;
 
 	sec = malloc(sizeof(*sec));
-- 
2.20.1

[Elftoolchain-developers] [PATCH 1/2] objtool: Rename elf_open to prevent conflict with libelf from elftoolchain

[Michael F. <mf...@mf...>]

Signed-off-by: Michael Forney <mf...@mf...>
---
 tools/objtool/check.c | 2 +-
 tools/objtool/elf.c   | 2 +-
 tools/objtool/elf.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 172f99195726..6ed46c36c54f 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2407,7 +2407,7 @@ int check(const char *_objname, bool orc)
 
 	objname = _objname;
 
-	file.elf = elf_open(objname, orc ? O_RDWR : O_RDONLY);
+	file.elf = elf_open_path(objname, orc ? O_RDWR : O_RDONLY);
 	if (!file.elf)
 		return 1;
 
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index e99e1be19ad9..4116f564a0b0 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -401,7 +401,7 @@ static int read_relas(struct elf *elf)
 	return 0;
 }
 
-struct elf *elf_open(const char *name, int flags)
+struct elf *elf_open_path(const char *name, int flags)
 {
 	struct elf *elf;
 	Elf_Cmd cmd;
diff --git a/tools/objtool/elf.h b/tools/objtool/elf.h
index e44ca5d51871..c59100d243ac 100644
--- a/tools/objtool/elf.h
+++ b/tools/objtool/elf.h
@@ -74,7 +74,7 @@ struct elf {
 };
 
 
-struct elf *elf_open(const char *name, int flags);
+struct elf *elf_open_path(const char *name, int flags);
 struct section *find_section_by_name(struct elf *elf, const char *name);
 struct symbol *find_symbol_by_offset(struct section *sec, unsigned long offset);
 struct symbol *find_symbol_by_name(struct elf *elf, const char *name);
-- 
2.20.1