elftoolchain-developers — Discussion on elftoolchain development.

Re: [Elftoolchain-developers] FreeBSD PowerPC64(LE) libelf config

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

On Wed, Sep 9, 2020 at 1:13 AM Brandon Bergren <bd...@fr...> wrote:
>
> From FreeBSD r361104 and r365489.
>
>
> Index: libelf/_libelf_config.h

Added in [r3872], thanks!

-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

[Elftoolchain-developers] FreeBSD PowerPC64(LE) libelf config

[Brandon B. <bd...@Fr...>]

>From FreeBSD r361104 and r365489.


Index: libelf/_libelf_config.h
===================================================================
--- libelf/_libelf_config.h	(revision 3871)
+++ libelf/_libelf_config.h	(working copy)
@@ -91,6 +91,16 @@
 #endif
 #define	LIBELF_CLASS		ELFCLASS32
 
+#elif	defined(__powerpc64__)
+
+#define	LIBELF_ARCH		EM_PPC64
+#if	__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define	LIBELF_BYTEORDER	ELFDATA2LSB
+#else
+#define	LIBELF_BYTEORDER	ELFDATA2MSB
+#endif
+#define	LIBELF_CLASS		ELFCLASS64
+
 #elif	defined(__powerpc__)
 
 #define	LIBELF_ARCH		EM_PPC


-- 
  Brandon Bergren
  bd...@Fr...

[Elftoolchain-developers] Use elftoolchain with an IDE

[brian f. <pol...@ya...>]

Hi,I made an application using elftoolchain on gcc. I was wondering if it's possible to use the elftoolchain headers on an eclipse based IDE. I tried adding gelf.h, libelf.h and elfdefinitions.h in my include path but I can't build. All the elftoolchain functions are undefined, i.e elf_begin, elf_update, etc. I'll appreciate any suggestion.

Re: [Elftoolchain-developers] Question about APIs

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

brian> I'm curious if there is a Elftoolchain function
brian> equivalent to gelf_offscn and gelf_update_phdr.

Thanks for the heads-up - I have filed ticket #591 to add these to libelf.

-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

[Elftoolchain-developers] Question about APIs

[brian f. <pol...@ya...>]

I'm curious if there is a Elftoolchain function equivalent to gelf_offscn and gelf_update_phdr. I didn't see them in the elftoolchain github h ttps://github.com/elftoolchain/elftoolchain/tree/trunk/libelf thanks

[Elftoolchain-developers] Problem modifying global variable using libelf

[silver k. <he...@ho...>]

I modified my code a bit, I can display the .data section header correctly and the contents of the .data section, but I'm still not able to use the get_data() function properly.
I thought in order to modify the global variable it would be calling get_data() and set data-> some_string; but I get the error from my previous post.

U U U U \^@ \^@ \^@ \^@ \^@ \^@ \^@ \^@  \^@ \^@ \^@ \^@
*** Error in './prog4' : double free or corruption (out)
\M^Y \M^Y \M^Y \M^Y \^@ \^@ \^@ \^@ Aborted (core dumped)

if I comment out the data ->some_string; line as I have I currently have below, I get the following output

\^@ \^@ \^@ \^@ \^@ \^@ \^@ \^@  \^@ \^@ \^@ \^@ \^@  \^@ \^@ \^@ \^@
 \^Q \^Q \^Q \^Q \M-+ \M-+ \M-+ \M-+

The "U" character represents some_string[] = {0x55555555}; this is what I'm passing to the data -> d_buf = some_string;
The "M^Y" character represents the other global variable I have defined in prog4.c other_string[] = {0x99999999};
The "\^Q" and "\M-+" are the contents of the global variables from hello.c
uint32_t test1 =0x11111111;
uint32_t test1 =0xabababab; respectively

ideally what I want to see for the output is this:

\^@ \^@ \^@ \^@ \^@ \^@ \^@ \^@  \^@ \^@ \^@ \^@ \^@  \^@ \^@ \^@ \^@
 U U U U  \M-+ \M-+ \M-+ \M-+

I'm assuming since other_string will be ignored since it's not being passed in the d_buf parameter. Again, any suggestion is appreciated thanks.

#include <err.h>
#include <fcntl.h>
#include <gelf.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <bsd/vis.h>

int main(int argc, char **argv)
{
    int fd;
    char *name, *p, pc[4*sizeof(char)];
    Elf_Scn *scn;
    Elf_Data *data;
    GElf_Shdr shdr;
    size_t n, shstrndx, sz;
    Elf *e;

    uint32_t some_string[1] = {0x55555555};
    uint32_t other_string[1] = {0x99999999};

    if (argc != 2)
        errx(EXIT_FAILURE, "usage: %s file-name", argv[0]);

    if (elf_version(EV_CURRENT) == EV_NONE)
        errx(EXIT_FAILURE, "ELF library initialization "
            "failed: %s", elf_errmsg(-1));

    if ((fd = open(argv[1], O_RDWR, 0)) < 0)
        err(EXIT_FAILURE, "open \%s\" failed", argv[1]);

    if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
        errx(EXIT_FAILURE, "elf_begin() failed: %s.",
            elf_errmsg(-1));

    if (elf_kind(e) != ELF_K_ELF)
        errx(EXIT_FAILURE, "%s is not an ELF object.",
            argv[1]);

    if (elf_getshdrstrndx(e, &shstrndx) != 0)
errx(EXIT_FAILURE, "elf_getshdrstrndx() failed: %s.",
   elf_errmsg(-1));

scn = NULL;

while((scn = elf_nextscn(e, scn)) != NULL) {

if (gelf_getshdr(scn, &shdr) != &shdr)
errx(EXIT_FAILURE, "gelf_getshdr() failed: %s.",
           elf_errmsg(-1));

if ((name = elf_strptr(e, shstrndx, shdr.sh_name)) == NULL)
errx(EXIT_FAILURE, "elf_strptr() failed: %s.",
           elf_errmsg(-1));

    if (strcmp(name, ".data") == 0)
{
break;
        }

}

data = NULL; n = 0;

    while (n < shdr.sh_size && (data = elf_getdata(scn, data))!= NULL){
(void) printf("Section %-4.4jd %s\n", (uintmax_t)
elf_ndxscn(scn), name);

//data ->d_buf = some_string;

p = (char * ) data->d_buf;
while(p < (char *) data-> d_buf + data->d_size) {
if(vis(pc, *p, VIS_WHITE, 0))
printf("%s", pc);
n++; p++;
(void) putchar((n % 16) ? ' ' : '\n');
}
}


    if(elf_update(e,ELF_C_NULL) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

//(void) elf_flagshdr(scn, ELF_C_SET, ELF_F_DIRTY);
(void) elf_flagscn(scn, ELF_C_SET, ELF_F_DIRTY);
(void) elf_flagdata(data, ELF_C_SET, ELF_F_DIRTY);
//(void) elf_flagehdr(e, ELF_C_SET, ELF_F_DIRTY);
(void) elf_flagelf(e, ELF_C_SET, ELF_F_DIRTY);

    if(elf_update(e,ELF_C_WRITE) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

    if(elf_flagelf(e,ELF_C_SET, ELF_F_LAYOUT) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

    (void) putchar('\n');

    (void) elf_end(e);
    (void) close(fd);
    exit(EXIT_SUCCESS);
}

[Elftoolchain-developers] Problem with writing to an elf file using libelf

[silver k. <he...@ho...>]

Hi Joseph,

Thanks for the answer, I made the changes you suggested.  In my previous post I said that after adding new data to the .data section, the .data section get moved to another memory address. I inspected this more carefully using readelf -S hello and I discovered is that actually none of the memory sections get moved around (as in all the memory sections start at the same address before and after editing the elf file) what changes is the Offset Align for the .data section from 1030 to 930 but it's still inside the memory range of the .data section, I'm not sure if this is good or bad.

My problem is that let's say I have two global variables defined in hello.c and I want to modify the value of the first variable, using the code that I have below, the program actually "overwrites" the variable with the value that I'm modifying and the second variable gets erased. Using the code that I have below I get an error "Error in ./prog4: double free or corruption(out): 0x00007ffd98fa9640 *** Aborted (core dumped).

My other question is how can I specify which global variable I want to modify? do I assign to the "data" type the offset align of the global data I want to modify? as in
data = offset align; ?


#include <err.h>
#include <fcntl.h>
#include <gelf.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <bsd/vis.h>

int
main(int argc, char **argv)
{

    int fd;
    Elf *e;
    char *name, *p, pc[4*sizeof(char)];
    Elf_Scn *scn;
    Elf_Data *data;
    GElf_Shdr shdr;
    GElf_Sym sym;
    size_t n, shstrndx, sz;

    uint32_t some_string[] = {0xaf};

    if (argc != 2)
        errx(EXIT_FAILURE, "usage: %s file-name", argv[0]);

    if (elf_version(EV_CURRENT) == EV_NONE)
        errx(EXIT_FAILURE, "ELF library initialization "
            "failed: %s", elf_errmsg(-1));

    if ((fd = open(argv[1], O_RDWR, 0)) < 0)
        err(EXIT_FAILURE, "open \%s\" failed", argv[1]);

    if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
        errx(EXIT_FAILURE, "elf_begin() failed: %s.",
            elf_errmsg(-1));

    if (elf_kind(e) != ELF_K_ELF)
        errx(EXIT_FAILURE, "%s is not an ELF object.",
            argv[1]);

    if ((scn = elf_getscn(e, 24)) == NULL)
errx(EXIT_FAILURE, "elf_scn() failed: %s.",
   elf_errmsg(-1));

    if (gelf_getshdr(scn, &shdr) != &shdr)
        errx(EXIT_FAILURE, "getshdr(shstrndx) failed: %s.",
            elf_errmsg(-1));

data = NULL;
    if ((data = elf_getdata(scn , data)) == NULL)
errx(EXIT_FAILURE, "elf_newdata() failed: %s.",
   elf_errmsg(-1));

    data ->d_align = 1;
    data ->d_off = 0LL;
    data ->d_buf = some_string;
    data ->d_type = ELF_T_WORD;
    data ->d_size = sizeof(some_string);
    data ->d_version = EV_CURRENT;

    (void) printf(".data: size=%jd\n", (uintmax_t)shdr.sh_size);

   if(elf_update(e,ELF_C_NULL) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

(void) elf_flagdata(data, ELF_C_SET, ELF_F_DIRTY);

   if(elf_update(e,ELF_C_WRITE) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

   if(elf_update(e,ELF_F_LAYOUT) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
elf_errmsg(-1));

    (void) putchar('\n');

    (void) elf_end(e);
    (void) close(fd);
    exit(EXIT_SUCCESS);
}

My hello.c file still the same. Thanks for any suggestions.

________________________________
From: Joseph Koshy <jko...@gm...> on behalf of Joseph Koshy <jk...@us...>
Sent: Sunday, June 21, 2020 3:42 PM
To: silver kapo <he...@ho...>
Cc: elf...@li... <elf...@li...>
Subject: Re: [Elftoolchain-developers] Problem with writing to an elf file using libelf

> I'm trying to modify the data of a global
> variable in a C file. I was able to write
> data to the .data section but I had two
> problems. The first one is that when I
> open the edited hex file I notice that my
> .data section has shifted from 0x1030(where
> my .data section starts in the elf file)
> to ~0x0930. And the second problem is that
> instead of overwriting in the address location
> of my global variable, it writes the data in
> the next memory address. I.E let's say the
> global variable is defined at 0x1030 the new
> data get written at 0x1031 instead of 0x1030.
...
>     if ((data = elf_newdata(scn)) == NULL)
> errx(EXIT_FAILURE, "elf_newdata() failed: %s.",
>    elf_errmsg(-1));

This call to elf_newdata() would add new data to
the section 'scn', changing its size and possibly
causing the layout of the ELF object to change.

If you would like to modify the existing content
of the section without changing its size or
layout, you could try the following:

- read in the section's contents using elf_getdata(),
- change the contents of the section (pointed to by the
  d_buf member of the Elf_Data descriptor returned
  by elf_getdata()),
- set the ELF_F_DIRTY flag on the Elf_Data descriptor
  using elf_flagdata(),
- call elf_update() as before.

You might also want to set the ELF_F_LAYOUT flag
on the Elf object, to turn off libelf's default
layout rules.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Problem with writing to an elf file using libelf

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

> I'm trying to modify the data of a global
> variable in a C file. I was able to write
> data to the .data section but I had two
> problems. The first one is that when I
> open the edited hex file I notice that my
> .data section has shifted from 0x1030(where
> my .data section starts in the elf file)
> to ~0x0930. And the second problem is that
> instead of overwriting in the address location
> of my global variable, it writes the data in
> the next memory address. I.E let's say the
> global variable is defined at 0x1030 the new
> data get written at 0x1031 instead of 0x1030.
...
>     if ((data = elf_newdata(scn)) == NULL)
> errx(EXIT_FAILURE, "elf_newdata() failed: %s.",
>    elf_errmsg(-1));

This call to elf_newdata() would add new data to
the section 'scn', changing its size and possibly
causing the layout of the ELF object to change.

If you would like to modify the existing content
of the section without changing its size or
layout, you could try the following:

- read in the section's contents using elf_getdata(),
- change the contents of the section (pointed to by the
  d_buf member of the Elf_Data descriptor returned
  by elf_getdata()),
- set the ELF_F_DIRTY flag on the Elf_Data descriptor
  using elf_flagdata(),
- call elf_update() as before.

You might also want to set the ELF_F_LAYOUT flag
on the Elf object, to turn off libelf's default
layout rules.

Regards,
Joseph Koshy

[Elftoolchain-developers] Problem with writing to an elf file using libelf

[silver k. <he...@ho...>]

Hello all,

I'm trying to modify the data of a global variable in a C file. I was able to write data to the .data section but I had two problems. The first one is that when I open the edited hex file I notice that my .data section has shifted from 0x1030(where my .data section starts in the elf file) to ~0x0930. And the second problem is that instead of overwriting in the address location of my global variable, it writes the data in the next memory address. I.E let's say the global variable is defined at 0x1030 the new data get written at 0x1031 instead of 0x1030.

I am using ubuntu 14.04 I was having problems with the vis.h file so I had to use -lbsd and #include <bsd/vis.h> in my file.

The elf file I'm using it's from my hello.c file. I compiled with gcc using gcc -o hello hello.c
and my libelf program is prog4.c and I compiled using cc -o prog4 prog4.c -lelf -lbsd
then I did ./prog4 hello

I opened the new hello elf file with a hex editor called Bless that can be installed with sudo apt-get Bless

this is my libelf program

**********************************************************************************

#include <err.h>
#include <fcntl.h>
#include <gelf.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <bsd/vis.h>

int
main(int argc, char **argv)
{

    int fd;
    Elf *e;
    char *name, *p, pc[4*sizeof(char)];
    Elf_Scn *scn;
    Elf_Data *data;
    GElf_Shdr shdr;
    GElf_Sym sym;
    size_t n, shstrndx, sz;

    uint32_t some_string[] = {0xaf};

    if (argc != 2)
        errx(EXIT_FAILURE, "usage: %s file-name", argv[0]);

    if (elf_version(EV_CURRENT) == EV_NONE)
        errx(EXIT_FAILURE, "ELF library initialization "
            "failed: %s", elf_errmsg(-1));

    if ((fd = open(argv[1], O_RDWR, 0)) < 0)
        err(EXIT_FAILURE, "open \%s\" failed", argv[1]);

    if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
        errx(EXIT_FAILURE, "elf_begin() failed: %s.",
            elf_errmsg(-1));

    if (elf_kind(e) != ELF_K_ELF)
        errx(EXIT_FAILURE, "%s is not an ELF object.",
            argv[1]);

    if ((scn = elf_getscn(e, 24)) == NULL)
errx(EXIT_FAILURE, "elf_scn() failed: %s.",
   elf_errmsg(-1));

    if (gelf_getshdr(scn, &shdr) != &shdr)
        errx(EXIT_FAILURE, "getshdr(shstrndx) failed: %s.",
            elf_errmsg(-1));

    if ((data = elf_newdata(scn)) == NULL)
errx(EXIT_FAILURE, "elf_newdata() failed: %s.",
   elf_errmsg(-1));

    data ->d_align = 1;
    data ->d_off = 0LL;
    data ->d_buf = some_string;
    data ->d_type = ELF_T_WORD;
    data ->d_size = sizeof(some_string);
    data ->d_version = EV_CURRENT;

    (void) printf(".data: size=%jd\n", (uintmax_t)shdr.sh_size);

   if(elf_update(e,ELF_C_NULL) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

    if(elf_update(e,ELF_C_WRITE) < 0 )
errx(EXIT_FAILURE, "elf_update(NULL) failed: %s.",
   elf_errmsg(-1));

    (void) putchar('\n');

    (void) elf_end(e);
    (void) close(fd);
    exit(EXIT_SUCCESS);
}

********************************************************************************

and this is my hello world program

********************************************************************************

#include <stdio.h>
#include <stdint.h>

uint8_t test = 0xce;
uint8_t  tuna = 0xab;

int main(){

printf("hello world\n");
return 0;
}


They are both very simple since I'm just testing. Any hints or suggestions are appreciated thanks.

Re: [Elftoolchain-developers] Building additional documentation

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

On Sat, Feb 29, 2020 at 8:57 PM Ed Maste <em...@fr...> wrote:

em> INSTALL contains a caution for FreeBSD:
...
em> Other operating systems have a similar
em> note. However, there is no issue building
em> on FreeBSD that I can see; the generated
em> libelf-by-example.pdf looks fine. Was there an
em> old issue that's no longer relevant perhaps?

I used to build additional documentation on (uptil)
FreeBSD 8.2 earlier -- the "latex-pgf" package
used to be a pre-requisite.

Per memory, I had trimmed the
INSTALL stanza for FreeBSD in [r3289]
<https://sourceforge.net/p/elftoolchain/code/3289>,
in a bid to keep my overheads down.

Please feel free to add it back though.

Regards,
Joseph Koshy

[Elftoolchain-developers] Building additional documentation

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

INSTALL contains a caution for FreeBSD:

> - Building additional documentation is not currently supported under
>   FreeBSD 11.3.

Other operating systems have a similar note. However, there is no
issue building on FreeBSD that I can see; the generated
libelf-by-example.pdf looks fine. Was there an old issue that's no
longer relevant perhaps?

[Elftoolchain-developers] ELF Tool Chain svn-git conversion

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

The current ELF Tool Chain git mirror[1] is produced using "git svn",
and doesn't correctly represent changes prior to r402, when the svn
repo was reorganized to match the standard svn layout. This conversion
is in the (currently default) trunk branch[2].

I have produced a prototype mirror using "svn2git", which does
translate the pre-r402 history. I also set up an author name map for
this conversion, using my preferred email address for my commits and
using names and email addresses from Sourceforge for others. (The
mapping can be adjusted prior to running the real conversion.)

This conversion is available in the master branch in my own ELF Tool
Chain github repo[3]. I invite others to review this conversion; if no
issues are found I expect to push it to the ELF Tool Chain GitHub
mirror in a week or so.

The scripts and tools for the conversion can be found in my
elftoolchain-git-mirror repo[4] on GitHub.

Note that this git mirror changes nothing with respect to the official
"source of truth" which remains the svn repository on SourceForge.

[1] https://github.com/elftoolchain/elftoolchain
[2] https://github.com/elftoolchain/elftoolchain/tree/trunk
[3] https://github.com/emaste/elftoolchain/tree/master
[4] https://github.com/emaste/elftoolchain-git-mirror/

Re: [Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

ed> Should the build glue (adding appropriate -I arguments, etc.) already
ed> be in place?

ed> I tried building the change on Ubuntu 18.04 via CI and it failed to
ed> find <sys/tree.h>.

The example programs in the libelf tutorial use "libbsd-dev".

To build on Ubuntu you may need something like the following to be
incorporated into your patch:

Index: addr2line.c
===================================================================
--- addr2line.c (revision 3822)
+++ addr2line.c (working copy)
@@ -25,6 +25,8 @@
  */

 #include <sys/param.h>
+#include <sys/tree.h>
+
 #include <dwarf.h>
 #include <err.h>
 #include <fcntl.h>
Index: os.Linux.mk
===================================================================
--- os.Linux.mk (nonexistent)
+++ os.Linux.mk (working copy)
@@ -0,0 +1,2 @@
+CFLAGS+=    -I/usr/include/bsd -DLIBBSD_OVERLAY
+LDADD+=     -lbsd


-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

Re: [Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

On Thu, 13 Feb 2020 at 16:13, Joseph Koshy <jk...@us...> wrote:
>
> > However this uses BSD's sys/tree.h, and I am not sure if it's
> > available on Linux distros. Once we have CI for Linux (or get advice
> > on sys/tree.h there) I will work on bringing these changes upstream.
>
> <sys/tree.h> would be part of the "libbsd-dev" package in
> Ubuntu/Debian ("libbsd-dev" is listed as a build pre-requisite).

Should the build glue (adding appropriate -I arguments, etc.) already
be in place?

I tried building the change on Ubuntu 18.04 via CI and it failed to
find <sys/tree.h>.

Re: [Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

jk> In https://reviews.freebsd.org/D23418 there is mention of increased
jk> memory usage, from 256K to 77M.  This seems a large increase; was it
jk> looked at in FreeBSD?

markj> This is stale and was due to a bug in an early version of the patch.  We
markj> did some heap profiling and found that the actual increase in memory
markj> usage from the patch is negligible (I believe tens of KB when resolving
markj> addresses in the FreeBSD kernel).

That is good to know - thanks for the clarification.

Thank you for folding these changes upstream.

-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

Re: [Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

On Thu, Feb 13, 2020 at 09:13:08PM +0000, Joseph Koshy via Elftoolchain-developers wrote:
> Ed,
> 
> > https://reviews.freebsd.org/rS357450
> > addr2line: Cache CU DIEs upon a successful address lookup
> 
> In https://reviews.freebsd.org/D23418 there is mention of increased
> memory usage, from 256K to 77M.  This seems a large increase; was it
> looked at in FreeBSD?

This is stale and was due to a bug in an early version of the patch.  We
did some heap profiling and found that the actual increase in memory
usage from the patch is negligible (I believe tens of KB when resolving
addresses in the FreeBSD kernel).

> The Minix microkernel is one of our supported OSes -- I would keep an
> eye on RAM usage so that the project remains usable there.
> 
> What is the specific problem that this patch is attempting to address?

The case where addr2line is consuming a large number of input addresses.
Today it sequentially scans the CU DIEs for each address without doing
any caching.

> > However this uses BSD's sys/tree.h, and I am not sure if it's
> > available on Linux distros. Once we have CI for Linux (or get advice
> > on sys/tree.h there) I will work on bringing these changes upstream.
> 
> <sys/tree.h> would be part of the "libbsd-dev" package in
> Ubuntu/Debian ("libbsd-dev" is listed as a build pre-requisite).
> 
> --
> Joseph Koshy | Volunteer Developer, The Elftoolchain Project
> 
> 
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

Re: [Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

Ed,

> https://reviews.freebsd.org/rS357450
> addr2line: Cache CU DIEs upon a successful address lookup

In https://reviews.freebsd.org/D23418 there is mention of increased
memory usage, from 256K to 77M.  This seems a large increase; was it
looked at in FreeBSD?

The Minix microkernel is one of our supported OSes -- I would keep an
eye on RAM usage so that the project remains usable there.

What is the specific problem that this patch is attempting to address?

> However this uses BSD's sys/tree.h, and I am not sure if it's
> available on Linux distros. Once we have CI for Linux (or get advice
> on sys/tree.h there) I will work on bringing these changes upstream.

<sys/tree.h> would be part of the "libbsd-dev" package in
Ubuntu/Debian ("libbsd-dev" is listed as a build pre-requisite).

--
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

Re: [Elftoolchain-developers] Ubuntu 17.10 is EOL

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

On Thu, 13 Feb 2020 at 10:28, Ed Maste <em...@fr...> wrote:
>
> On Thu, 13 Feb 2020 at 10:18, Ed Maste <em...@fr...> wrote:
> >
> > It seems that Ubuntu 17.10 is our currently supported Linux version,
> > but it went EOL as of July 2018. 18.04 is likely a good choice as it
> > is supported until 2028. However, I don't normally use Linux; it would
> > be good if someone can make sure ELF Tool Chain builds on 18.04 and
> > then add a build config to CI (.cirrus.yml).
>
> I tried Ubuntu 16.04 (the previous LTS release, that is still
> supported) but it fails with an unrecognized cc command line option.
> Someone who uses Linux is going to have to pick this up.

Oh, it seems INSTALL was updated for Ubuntu 18.04 in r3795 but the
"Supported Operating Systems" table didn't receive the corresponding
change. I'm trying a build on 18.04 via CI now and will update the
table in INSTALL if it completes.

[Elftoolchain-developers] addr2line improvements - sys/tree.h on Linux

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

One of the FreeBSD Foundation's co-op students has made some
enhancements to addr2line in FreeBSD to improve performance and
correctness:

https://reviews.freebsd.org/rS357450
addr2line: Cache CU DIEs upon a successful address lookup.

https://reviews.freebsd.org/rS357844
addr2line: Handle DW_AT_ranges in compile units

I have these merged to ELF Tool Chain in the "addr2line" branch in my git fork:
https://github.com/emaste/elftoolchain/tree/addr2line

However this uses BSD's sys/tree.h, and I am not sure if it's
available on Linux distros. Once we have CI for Linux (or get advice
on sys/tree.h there) I will work on bringing these changes upstream.

Re: [Elftoolchain-developers] Ubuntu 17.10 is EOL

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

On Thu, 13 Feb 2020 at 10:18, Ed Maste <em...@fr...> wrote:
>
> It seems that Ubuntu 17.10 is our currently supported Linux version,
> but it went EOL as of July 2018. 18.04 is likely a good choice as it
> is supported until 2028. However, I don't normally use Linux; it would
> be good if someone can make sure ELF Tool Chain builds on 18.04 and
> then add a build config to CI (.cirrus.yml).

I tried Ubuntu 16.04 (the previous LTS release, that is still
supported) but it fails with an unrecognized cc command line option.
Someone who uses Linux is going to have to pick this up.

[Elftoolchain-developers] Ubuntu 17.10 is EOL

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

It seems that Ubuntu 17.10 is our currently supported Linux version,
but it went EOL as of July 2018. 18.04 is likely a good choice as it
is supported until 2028. However, I don't normally use Linux; it would
be good if someone can make sure ELF Tool Chain builds on 18.04 and
then add a build config to CI (.cirrus.yml).

Re: [Elftoolchain-developers] Overall status from ELF Tool Chain test suite

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

On Sat, 8 Feb 2020 at 17:31, Joseph Koshy <jk...@us...> wrote:
>
> As of [r3818], test failures are propagated to the invoking make(1) process.

Thank you - indeed, the test runs are now red in Cirrus-CI.
https://cirrus-ci.com/build/5940794091634688

AFAIK all failing elfcopy tests are comparing against an expected
binary output and the order of the strings in .shstrtab changed after
markj's commit - i.e., the test legitimately detected change in the
output, but the change is actually benign and the fix is to update the
expected output. Of course I'd make that change only after comparing
the output and ensuring that ordering in the string table is the only
difference.

Re: [Elftoolchain-developers] Overall status from ELF Tool Chain test suite

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

e.m> Is there an existing way to get a pass/fail from the test suite?
j.k> I'll take this up.

As of [r3818], test failures are propagated to the invoking make(1) process.

-- 
Joseph Koshy

Re: [Elftoolchain-developers] Overall status from ELF Tool Chain test suite

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

On Fri, Feb 7, 2020 at 6:55 PM Ed Maste <em...@fr...> wrote:
> I submitted ticket #579 for this issue but I think it's worthwhile
> raising it here for discussion. I can't find an easy way to determine
> an overall status (pass or fail) from the test suite. For the issue I
> just investigated (ticket #575) I bisected the failure by having the
> bisect script run "grep 'not ok' test.log" but this is awkward.

> Is there an existing way to get a pass/fail from the test suite?

I'll take this up.

-- 
Joseph Koshy

[Elftoolchain-developers] Overall status from ELF Tool Chain test suite

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

I submitted ticket #579 for this issue but I think it's worthwhile
raising it here for discussion. I can't find an easy way to determine
an overall status (pass or fail) from the test suite. For the issue I
just investigated (ticket #575) I bisected the failure by having the
bisect script run "grep 'not ok' test.log" but this is awkward.

Is there an existing way to get a pass/fail from the test suite?