You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(10) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(7) |
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
2010 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(4) |
May
|
Jun
(4) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(6) |
Nov
(1) |
Dec
|
2011 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(11) |
Nov
(8) |
Dec
(1) |
2012 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(10) |
2013 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(20) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
2015 |
Jan
(3) |
Feb
(26) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(6) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
(20) |
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
(15) |
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
2025 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Joseph K. <jk...@us...> - 2020-09-10 06:33:39
|
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 |
From: Brandon B. <bd...@Fr...> - 2020-09-09 00:13:22
|
>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... |
From: brian f. <pol...@ya...> - 2020-07-23 04:34:04
|
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. |
From: Joseph K. <jk...@us...> - 2020-07-07 20:26:25
|
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 |
From: brian f. <pol...@ya...> - 2020-07-06 22:53:17
|
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 |
From: silver k. <he...@ho...> - 2020-06-23 02:29:37
|
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); } |
From: silver k. <he...@ho...> - 2020-06-22 04:51:13
|
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 |
From: Joseph K. <jk...@us...> - 2020-06-21 20:42:49
|
> 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 |
From: silver k. <he...@ho...> - 2020-06-21 05:45:14
|
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. |
From: Joseph K. <jk...@us...> - 2020-03-01 19:19:01
|
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 |
From: Ed M. <em...@fr...> - 2020-02-29 20:57:31
|
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? |
From: Ed M. <em...@fr...> - 2020-02-24 21:16:32
|
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/ |
From: Joseph K. <jk...@us...> - 2020-02-14 22:34:53
|
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 |
From: Ed M. <em...@fr...> - 2020-02-13 23:53:58
|
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>. |
From: Joseph K. <jk...@us...> - 2020-02-13 22:47:01
|
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 |
From: Mark J. <ma...@fr...> - 2020-02-13 21:19:40
|
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 |
From: Joseph K. <jk...@us...> - 2020-02-13 21:13:27
|
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 |
From: Ed M. <em...@fr...> - 2020-02-13 15:49:29
|
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. |
From: Ed M. <em...@fr...> - 2020-02-13 15:41:42
|
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. |
From: Ed M. <em...@fr...> - 2020-02-13 15:29:09
|
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. |
From: Ed M. <em...@fr...> - 2020-02-13 15:18:54
|
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). |
From: Ed M. <em...@fr...> - 2020-02-11 22:15:56
|
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. |
From: Joseph K. <jk...@us...> - 2020-02-08 22:31:23
|
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 |
From: Joseph K. <jk...@us...> - 2020-02-08 14:06:40
|
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 |
From: Ed M. <em...@fr...> - 2020-02-07 18:55:18
|
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? |