elftoolchain-developers — Discussion on elftoolchain development.

[Elftoolchain-developers] [elftoolchain][PATCH] readelf(1): fix -wR option, memory leaks, and -wf minor bug

[Christos M. <chr...@ma...>]

Fixed broken -wR option, and various memory leaks.
Relevant PR: https://reviews.freebsd.org/D38419

---
 readelf/readelf.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/readelf/readelf.c b/readelf/readelf.c
index d3b1bb51..134bf0bf 100644
--- a/readelf/readelf.c
+++ b/readelf/readelf.c
@@ -4701,8 +4701,10 @@ dump_dwarf_line(struct readelf *re)
 			return;
 		}
 		if (dwarf_attrval_unsigned(die, DW_AT_stmt_list, &offset,
-		    &de) != DW_DLV_OK)
+		    &de) != DW_DLV_OK) {
+			dwarf_dealloc(re->dbg, die, DW_DLA_DIE);
 			continue;
+		}
 
 		length = re->dw_read(d, &offset, 4);
 		if (length == 0xffffffff) {
@@ -4713,6 +4715,7 @@ dump_dwarf_line(struct readelf *re)
 
 		if (length > d->d_size - offset) {
 			warnx("invalid .dwarf_line section");
+			dwarf_dealloc(re->dbg, die, DW_DLA_DIE);
 			continue;
 		}
 
@@ -4913,6 +4916,7 @@ dump_dwarf_line(struct readelf *re)
 
 
 		}
+		dwarf_dealloc(re->dbg, die, DW_DLA_DIE);
 	}
 	if (ret == DW_DLV_ERROR)
 		warnx("dwarf_next_cu_header: %s", dwarf_errmsg(de));
@@ -4955,9 +4959,9 @@ dump_dwarf_line_decoded(struct readelf *re)
 		printf("%-37s %11s   %s\n", "Filename", "Line Number",
 		    "Starting Address");
 		if (dwarf_srclines(die, &linebuf, &linecount, &de) != DW_DLV_OK)
-			continue;
+			goto done;
 		if (dwarf_srcfiles(die, &srcfiles, &srccount, &de) != DW_DLV_OK)
-			continue;
+			goto done;
 		for (i = 0; i < linecount; i++) {
 			ln = linebuf[i];
 			if (dwarf_line_srcfileno(ln, &fn, &de) != DW_DLV_OK)
@@ -4971,6 +4975,8 @@ dump_dwarf_line_decoded(struct readelf *re)
 			    (uintmax_t) lineaddr);
 		}
 		putchar('\n');
+done:
+		dwarf_dealloc(re->dbg, die, DW_DLA_DIE);
 	}
 }
 
@@ -5603,7 +5609,8 @@ dump_dwarf_ranges_foreach(struct readelf *re, Dwarf_Die die, Dwarf_Addr base)
 	Dwarf_Addr base0;
 	Dwarf_Half attr;
 	Dwarf_Signed attr_count, cnt;
-	Dwarf_Unsigned off, bytecnt;
+	Dwarf_Unsigned bytecnt;
+	Dwarf_Off off;
 	int i, j, ret;
 
 	if ((ret = dwarf_attrlist(die, &attr_list, &attr_count, &de)) !=
@@ -5620,8 +5627,9 @@ dump_dwarf_ranges_foreach(struct readelf *re, Dwarf_Die die, Dwarf_Addr base)
 		}
 		if (attr != DW_AT_ranges)
 			continue;
-		if (dwarf_formudata(attr_list[i], &off, &de) != DW_DLV_OK) {
-			warnx("dwarf_formudata failed: %s", dwarf_errmsg(de));
+		if (dwarf_global_formref(attr_list[i], &off, &de) != DW_DLV_OK) {
+			warnx("dwarf_global_formred failed: %s",
+			    dwarf_errmsg(de));
 			continue;
 		}
 		if (dwarf_get_ranges(re->dbg, (Dwarf_Off) off, &ranges, &cnt,
@@ -5663,6 +5671,8 @@ cont_search:
 		warnx("dwarf_siblingof: %s", dwarf_errmsg(de));
 	else if (ret == DW_DLV_OK)
 		dump_dwarf_ranges_foreach(re, ret_die, base);
+
+	dwarf_dealloc(re->dbg, die, DW_DLA_DIE);
 }
 
 static void
@@ -5966,7 +5976,7 @@ dump_dwarf_frame_section(struct readelf *re, struct section *s, int alt)
 	Dwarf_Small cie_version;
 	Dwarf_Ptr fde_addr, fde_inst, cie_inst;
 	char *cie_aug, c;
-	int i, eh_frame;
+	int i, ret, eh_frame;
 	Dwarf_Error de;
 
 	printf("\nThe section %s contains:\n\n", s->name);
@@ -5981,10 +5991,13 @@ dump_dwarf_frame_section(struct readelf *re, struct section *s, int alt)
 		}
 	} else if (!strcmp(s->name, ".eh_frame")) {
 		eh_frame = 1;
-		if (dwarf_get_fde_list_eh(re->dbg, &cie_list, &cie_count,
-		    &fde_list, &fde_count, &de) != DW_DLV_OK) {
-			warnx("dwarf_get_fde_list_eh failed: %s",
-			    dwarf_errmsg(de));
+		ret = dwarf_get_fde_list_eh(re->dbg, &cie_list, &cie_count,
+		    &fde_list, &fde_count, &de);
+		if (ret != DW_DLV_OK) {
+			if (ret == DW_DLV_ERROR) {
+				warnx("dwarf_get_fde_list_eh failed: %s",
+				    dwarf_errmsg(de));
+			}
 			return;
 		}
 	} else
-- 
2.39.2

[Elftoolchain-developers] [PATCH] Allow Elf_Data with d_buf=NULL if d_size=0

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

---
Linux 5.14.15 included a patch to fix the issue I posted about
several months ago (it now sets the section type before
gelf_update_rel[a]), but unfortunately 5.14 introduced a new issue
[0] caused by an implicitly created empty Elf_Data. I think this
would be more awkward to change in objtool, and it seems reasonable
to me that elftoolchain should allow NULL d_buf if d_size is 0.

[0] https://github.com/oasislinux/oasis/blob/master/pkg/elftoolchain/patch/0005-Allow-empty-Elf_Data.patch

 libelf/elf_update.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libelf/elf_update.c b/libelf/elf_update.c
index baf64809..4fe663d3 100644
--- a/libelf/elf_update.c
+++ b/libelf/elf_update.c
@@ -818,6 +818,9 @@ _libelf_write_scn(Elf *e, unsigned char *nf, struct _Elf_Extent *ex)
 
 		rc = (off_t) (sh_off + d->d_off);
 
+		if (d->d_size == 0)
+			continue;
+
 		assert(d->d_buf != NULL);
 		assert(d->d_version == e->e_version);
 		assert(d->d_size % msz == 0);
-- 
2.32.0

Re: [Elftoolchain-developers] [patch] consistently exit with status 0 if --help is specified

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

On Thu, Sep 2, 2021 at 9:43 PM Mark Johnston <ma...@fr...> wrote:

> I noticed that elftoolchain utilities are inconsistent with respect to
> the exit status when --help is specified.  (Some software will test the
> status for some reason before proceeding to actually use the utility.)
> binutils equivalents consistently exit with status 0, so I expect it
> makes sense for elftoolchain to do the same.

Changed in r3950, thanks.

--
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

[Elftoolchain-developers] [patch] consistently exit with status 0 if --help is specified

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

Hi,

I noticed that elftoolchain utilities are inconsistent with respect to
the exit status when --help is specified.  (Some software will test the
status for some reason before proceeding to actually use the utility.)
binutils equivalents consistently exit with status 0, so I expect it
makes sense for elftoolchain to do the same.

Thanks,
-Mark

diff --git a/addr2line/addr2line.c b/addr2line/addr2line.c
index 80bb753f..be534305 100644
--- a/addr2line/addr2line.c
+++ b/addr2line/addr2line.c
@@ -101,10 +101,10 @@ Usage: %s [options] hexaddress...\n\
   -V      | --version         Print a version identifier and exit.\n"
 
 static void
-usage(void)
+usage(int status)
 {
 	(void) fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
-	exit(1);
+	exit(status);
 }
 
 static void
@@ -689,11 +689,11 @@ main(int argc, char **argv)
 			base = 1;
 			break;
 		case 'H':
-			usage();
+			usage(0);
 		case 'V':
 			version();
 		default:
-			usage();
+			usage(1);
 		}
 	}
 
diff --git a/elfcopy/main.c b/elfcopy/main.c
index 78d5748c..940bfb78 100644
--- a/elfcopy/main.c
+++ b/elfcopy/main.c
@@ -233,7 +233,7 @@ static void	set_input_target(struct elfcopy *ecp, const char *target_name);
 static void	set_osabi(struct elfcopy *ecp, const char *abi);
 static void	set_output_target(struct elfcopy *ecp, const char *target_name);
 static void	strip_main(struct elfcopy *ecp, int argc, char **argv);
-static void	strip_usage(void);
+static void	strip_usage(int status);
 
 /*
  * An ELF object usually has a structure described by the
@@ -1185,8 +1185,9 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
 			ecp->strip = STRIP_UNNEEDED;
 			break;
 		case 'h':
+			strip_usage(EXIT_SUCCESS);
 		default:
-			strip_usage();
+			strip_usage(EXIT_FAILURE);
 		}
 	}
 
@@ -1199,13 +1200,13 @@ strip_main(struct elfcopy *ecp, int argc, char **argv)
 	    lookup_symop_list(ecp, NULL, SYMOP_STRIP) == NULL)
 		ecp->strip = STRIP_ALL;
 	if (argc == 0)
-		strip_usage();
+		strip_usage(EXIT_FAILURE);
 	/*
 	 * Only accept a single input file if an output file had been
 	 * specified.
 	 */
 	if (outfile != NULL && argc != 1)
-		strip_usage();
+		strip_usage(EXIT_FAILURE);
 
 	for (i = 0; i < argc; i++)
 		create_file(ecp, argv[i], outfile);
@@ -1543,10 +1544,10 @@ Usage: %s [options] file...\n\
   -X | --discard-locals           Remove compiler-generated local symbols.\n"
 
 static void
-strip_usage(void)
+strip_usage(int status)
 {
 	(void) fprintf(stderr, STRIP_USAGE_MESSAGE, ELFTC_GETPROGNAME());
-	exit(EXIT_FAILURE);
+	exit(status);
 }
 
 static void
diff --git a/size/size.c b/size/size.c
index 4976fceb..aa8a76a8 100644
--- a/size/size.c
+++ b/size/size.c
@@ -104,7 +104,7 @@ static void	show_version(void);
 static void	sysv_header(const char *, Elf_Arhdr *);
 static void	sysv_footer(void);
 static void	sysv_calc(Elf *, GElf_Ehdr *, GElf_Shdr *);
-static void	usage(void);
+static void	usage(int);
 static void	tbl_new(int);
 static void	tbl_print(const char *, int);
 static void	tbl_print_num(uint64_t, enum radix_style, int);
@@ -162,7 +162,7 @@ main(int argc, char **argv)
 				else {
 					warnx("unrecognized format \"%s\".",
 					      optarg);
-					usage();
+					usage(EXIT_FAILURE);
 				}
 				break;
 			case OPT_RADIX:
@@ -176,7 +176,7 @@ main(int argc, char **argv)
 				else {
 					warnx("unsupported radix \"%s\".",
 					      optarg);
-					usage();
+					usage(EXIT_FAILURE);
 				}
 				break;
 			default:
@@ -185,9 +185,11 @@ main(int argc, char **argv)
 			}
 			break;
 		case 'h':
+			usage(EXIT_SUCCESS);
+			/* NOTREACHED */
 		case '?':
 		default:
-			usage();
+			usage(EXIT_FAILURE);
 			/* NOTREACHED */
 		}
 	argc -= optind;
@@ -912,10 +914,10 @@ Usage: %s [options] file ...\n\
   -x                 Equivalent to `--radix=16'.\n"
 
 static void
-usage(void)
+usage(int status)
 {
 	(void) fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
-	exit(EXIT_FAILURE);
+	exit(status);
 }
 
 static void
diff --git a/strings/strings.c b/strings/strings.c
index 00e59868..20fb2e67 100644
--- a/strings/strings.c
+++ b/strings/strings.c
@@ -90,7 +90,7 @@ int	handle_elf(const char *, int);
 int	handle_binary(const char *, int);
 int	find_strings(const char *, off_t, off_t);
 void	show_version(void);
-void	usage(void);
+void	usage(int status);
 
 /*
  * strings(1) extracts text(contiguous printable characters)
@@ -132,7 +132,7 @@ main(int argc, char **argv)
 				encoding = ENCODING_32BIT_LITTLE;
 				encoding_size = 4;
 			} else
-				usage();
+				usage(EXIT_FAILURE);
 			        /* NOTREACHED */
 			break;
 		case 'f':
@@ -157,7 +157,7 @@ main(int argc, char **argv)
 			else if (*optarg == 'x')
 				radix = RADIX_HEX;
 			else
-				usage();
+				usage(EXIT_FAILURE);
 			        /* NOTREACHED */
 			break;
 		case 'v':
@@ -178,9 +178,11 @@ main(int argc, char **argv)
 			min_len += ch - '0';
 			break;
 		case 'h':
+			usage(EXIT_SUCCESS);
+			/* NOTREACHED */
 		case '?':
 		default:
-			usage();
+			usage(EXIT_FAILURE);
 			/* NOTREACHED */
 		}
 	}
@@ -432,11 +434,11 @@ Usage: %s [options] [file...]\n\
   -v     | --version           Print a version identifier and exit.\n"
 
 void
-usage(void)
+usage(int status)
 {
 
 	fprintf(stderr, USAGE_MESSAGE, ELFTC_GETPROGNAME());
-	exit(EXIT_FAILURE);
+	exit(status);
 }
 
 void

[Elftoolchain-developers] IRIX Support?

[Kazuo K. <ka...@ir...>]

Hello there,

I'm inquiring to ask if I could entice the developers here to add IRIX 
support. I am more than interested in doing so myself, but I've not yet 
fully studied your codebase, so I just wanted to open dialogue and "put 
the bug in your ear" so to speak.

Now, because you may be asking, let me give you the "why":

SGI IRIX is a proprietary OS, yes, but I (the admin of IRIXNet) am 
working on developing continuously for the OS despite its 
discontinuation. To that end, getting modern UNIX tools such as nm, 
strip, ar etc. would be nice to replace those on IRIX.

IRIX currently would be able to use all of the utils with the exception 
of ranlib - as those operations of libraries are done transparently by 
our linker. It may also help with obtaining compatibility on Solaris 
(IRIX has similarities to Solaris 8 and 9)  and other System V ones.

Before you ask, I have an SGI IRIX server I am more than happy to 
provide access to. Please let me know if I can be of assistance. I am 
currently running my own builds to try and get it working, and if I find 
any patches that can help them build, I will.

Best Regards!

Kazuo Kuroi

Re: [Elftoolchain-developers] gelf_update_rela with newly created section

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

m.f> Alternatively, an arguably better check is to make sure the Elf_Data
m.f> has d_type == ELF_T_REL(A). What are your thoughts on that?

The suggested change looks cleaner at the first glance, but is also a
change that could break existing code.

This is because elf_newdata(3) initializes the 'd_type' field of the
returned Elf_Data descriptor to 'ELF_T_BYTE'.  Applications do need to
override this value eventually, but can currently do so any time
before the call to elf_update(3).

With this change applications would need to set 'd_type' before
calling the gelf_update_rel{,a}() APIs, which is a new behavioral
requirement.

-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

Re: [Elftoolchain-developers] gelf_update_rela with newly created section

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

Michael Forney <mf...@mf...> wrote:
> I agree that the sanity check is good in general, but I have to
> wonder if it makes sense to fail if the section type is just not
> yet set (SHT_NULL), since that does not necessarily indicate an
> application error.

Alternatively, an arguably better check is to make sure the Elf_Data
has d_type == ELF_T_REL(A). What are your thoughts on that?

diff --git a/libelf/gelf_rel.c b/libelf/gelf_rel.c
index 60332597..3ff48647 100644
--- a/libelf/gelf_rel.c
+++ b/libelf/gelf_rel.c
@@ -42,7 +42,6 @@ gelf_getrel(Elf_Data *ed, int ndx, GElf_Rel *dst)
 	Elf *e;
 	size_t msz;
 	Elf_Scn *scn;
-	uint32_t sh_type;
 	Elf32_Rel *rel32;
 	Elf64_Rel *rel64;
 	struct _Libelf_Data *d;
@@ -59,12 +58,7 @@ gelf_getrel(Elf_Data *ed, int ndx, GElf_Rel *dst)
 	ec = e->e_class;
 	assert(ec == ELFCLASS32 || ec == ELFCLASS64);
 
-	if (ec == ELFCLASS32)
-		sh_type = scn->s_shdr.s_shdr32.sh_type;
-	else
-		sh_type = scn->s_shdr.s_shdr64.sh_type;
-
-	if (_libelf_xlate_shtype(sh_type) != ELF_T_REL) {
+	if (d->d_data.d_type != ELF_T_REL) {
 		LIBELF_SET_ERROR(ARGUMENT, 0);
 		return (NULL);
 	}
@@ -104,7 +98,6 @@ gelf_update_rel(Elf_Data *ed, int ndx, GElf_Rel *dr)
 	Elf *e;
 	size_t msz;
 	Elf_Scn *scn;
-	uint32_t sh_type;
 	Elf32_Rel *rel32;
 	Elf64_Rel *rel64;
 	struct _Libelf_Data *d;
@@ -121,12 +114,7 @@ gelf_update_rel(Elf_Data *ed, int ndx, GElf_Rel *dr)
 	ec = e->e_class;
 	assert(ec == ELFCLASS32 || ec == ELFCLASS64);
 
-	if (ec == ELFCLASS32)
-		sh_type = scn->s_shdr.s_shdr32.sh_type;
-	else
-		sh_type = scn->s_shdr.s_shdr64.sh_type;
-
-	if (_libelf_xlate_shtype(sh_type) != ELF_T_REL) {
+	if (d->d_data.d_type != ELF_T_REL) {
 		LIBELF_SET_ERROR(ARGUMENT, 0);
 		return (0);
 	}
diff --git a/libelf/gelf_rela.c b/libelf/gelf_rela.c
index 40462248..71d7e82a 100644
--- a/libelf/gelf_rela.c
+++ b/libelf/gelf_rela.c
@@ -42,7 +42,6 @@ gelf_getrela(Elf_Data *ed, int ndx, GElf_Rela *dst)
 	Elf *e;
 	size_t msz;
 	Elf_Scn *scn;
-	uint32_t sh_type;
 	Elf32_Rela *rela32;
 	Elf64_Rela *rela64;
 	struct _Libelf_Data *d;
@@ -59,12 +58,7 @@ gelf_getrela(Elf_Data *ed, int ndx, GElf_Rela *dst)
 	ec = e->e_class;
 	assert(ec == ELFCLASS32 || ec == ELFCLASS64);
 
-	if (ec == ELFCLASS32)
-		sh_type = scn->s_shdr.s_shdr32.sh_type;
-	else
-		sh_type = scn->s_shdr.s_shdr64.sh_type;
-
-	if (_libelf_xlate_shtype(sh_type) != ELF_T_RELA) {
+	if (d->d_data.d_type != ELF_T_RELA) {
 		LIBELF_SET_ERROR(ARGUMENT, 0);
 		return (NULL);
 	}
@@ -105,7 +99,6 @@ gelf_update_rela(Elf_Data *ed, int ndx, GElf_Rela *dr)
 	Elf *e;
 	size_t msz;
 	Elf_Scn *scn;
-	uint32_t sh_type;
 	Elf32_Rela *rela32;
 	Elf64_Rela *rela64;
 	struct _Libelf_Data *d;
@@ -122,12 +115,7 @@ gelf_update_rela(Elf_Data *ed, int ndx, GElf_Rela *dr)
 	ec = e->e_class;
 	assert(ec == ELFCLASS32 || ec == ELFCLASS64);
 
-	if (ec == ELFCLASS32)
-		sh_type = scn->s_shdr.s_shdr32.sh_type;
-	else
-		sh_type = scn->s_shdr.s_shdr64.sh_type;
-
-	if (_libelf_xlate_shtype(sh_type) != ELF_T_RELA) {
+	if (d->d_data.d_type != ELF_T_RELA) {
 		LIBELF_SET_ERROR(ARGUMENT, 0);
 		return (0);
 	}

Re: [Elftoolchain-developers] gelf_update_rela with newly created section

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

Thanks for your response. My apologies for the empty subject. I hit
send before realizing I forgot to write one.

Joseph Koshy <jk...@us...> wrote:
> > It appears that elftoolchain has a check[1] in gelf_update_rel[a] to
> > make sure that the section header corresponding to the GElf_Data has
> > the appropriate type, and it fails if not.
> 
> Yes, its a sanity check - since using gelf_update_rel{,a}() by mistake
> on data descriptors associated another section type could cause hard
> to diagnose data corruption.
> 
> Would it be possible to set the section type in your application
> before using these functions?

Unfortunately it is not my application, but a tool required to build
the Linux kernel. I have written a patch[0] which fixes the issue,
and I can try to submit it upstream.

I agree that the sanity check is good in general, but I have to
wonder if it makes sense to fail if the section type is just not
yet set (SHT_NULL), since that does not necessarily indicate an
application error.

[0] https://github.com/oasislinux/linux/commit/85ca71562234d8e5743cfa241bc3f445b6cc9a05

Re: [Elftoolchain-developers] (no subject)

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

> It appears that elftoolchain has a check[1] in gelf_update_rel[a] to
> make sure that the section header corresponding to the GElf_Data has
> the appropriate type, and it fails if not.

Yes, its a sanity check - since using gelf_update_rel{,a}() by mistake
on data descriptors associated another section type could cause hard
to diagnose data corruption.

Would it be possible to set the section type in your application
before using these functions?

Regards,
Joseph Koshy

-- 
Joseph Koshy | Volunteer Developer, The Elftoolchain Project

Re: [Elftoolchain-developers] [PATCH] readelf: remove unnecessary '; ' after function definition

[Joseph K. <jko...@gm...>]

> This is not allowed by the ISO C grammar.

Applied in r3949, thanks!

Regards,
Joseph Koshy

[Elftoolchain-developers] [PATCH] readelf: remove unnecessary '; ' after function definition

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

This is not allowed by the ISO C grammar.
---
 readelf/readelf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/readelf/readelf.c b/readelf/readelf.c
index d3b1bb51..7dafd341 100644
--- a/readelf/readelf.c
+++ b/readelf/readelf.c
@@ -458,7 +458,7 @@ elf_osabi(unsigned int abi)
 		snprintf(s_abi, sizeof(s_abi), "<unknown: %#x>", abi);
 		return (s_abi);
 	}
-};
+}
 
 static const char *
 elf_machine(unsigned int mach)
-- 
2.31.1

[Elftoolchain-developers] (no subject)

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

Hi,

I'm looking for some advice for an issue I hit with some recent
changes to Linux objtool.

Since [0], objtool calls gelf_update_rel[a] to write relocations to
newly created sections rather than writing to a raw array of GElf_Rel
itself. However, the section header is not updated until later when
the ELF file is written back to disk.

It appears that elftoolchain has a check[1] in gelf_update_rel[a] to
make sure that the section header corresponding to the GElf_Data has
the appropriate type, and it fails if not.

Is this a bug in objtool using the libelf API incorrectly, or is
elftoolchain being a bit too eager in its checks? Perhaps it could
skip the check if sh_type == SHT_NULL?

Thanks for any help!

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1a664ece586457e9f7652b0bc5b08386259e358
[1] https://sourceforge.net/p/elftoolchain/code/HEAD/tree/trunk/libelf/gelf_rela.c#l69

Re: [Elftoolchain-developers] [proposal] merge with LLVM?

[Joseph K. <jko...@gm...>]

jens> Has this been discussed before and what are the reasons not to merge
jens> with LLVM?

Thank you for your email.

The licensing, build systems, target platforms and project
directions differ for the two projects.  These aspects in
themselves would preclude a simple project merge.

But more importantly, the number of volunteer hours available
for coding or project management would remain the same
irrespective of the banner under which the volunteer work
happens.  It is not clear to me how a change of banner would
make a difference here.

Most open-source projects today are unsustainable for their
developers.  Please see the following study:

  Software Below the Poverty Line
  https://staltz.com/software-below-the-poverty-line.html

For some developers their open-source maintainership
responsibilities also negatively affect their employability.
This is because typical employment contracts assert complete
ownership over work by employees (even the employee's free
time work).  Between two candidates of equal merit, the one
requiring no changes to the standard employment contract would
be the easier hire.

These are some of the reasons why open-source maintainer
burnout isn't uncommon.  Please see:

  Burn out and/or quitting open source
  https://github.com/bzg/opensource-challenges

>From what I can see, long running open-source projects tend
to fall into one of a few camps:

1. Projects with a corporate core and a transient volunteer
   base.

   In these projects a handful of salaried employees maintain
   project continuity, while the unpaid contributors join,
   contribute for a few years, and then leave.

2. Projects hosted in academia (i.e. effectively tax-payer
   funded in some countries), where a steady stream of
   researchers and students keep the projects going while
   earning their degrees.

3. Projects whose maintainers willingly take the personal hit,
   in service to some higher ideology.

4. Free time (hobby) projects, where people write code because
   they like writing code.

Personally speaking, I treat *BSD work as being in category '4'.
This means that I prioritize what I personally find to be
interesting, given the limited number of volunteer hours
available.

I am not against working closely with a different project such
as LLVM - why duplicate effort after all - but I would not
want to take on commitments without also having the ability
to deliver them in a timely manner.

This means that sustainability would need to be addressed first.

Suggestions for improving project sustainability would be welcome.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] libelf and linux objtool

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

m.f> 4. This is a bit unrelated to objtool, but I noticed that
m.f> elfdefinitions.h contains several enums with values that
m.f> are too big for int (specifically, EF_PPC_EMB, SHF_COMDEF,
m.f> SHF_MIPS_STRING, SHF_EXCLUDE, SHF_MASKPROC, SHT_LOUSER, and
m.f> SHT_HIUSER). The C standard says that all enumerator values
m.f> must be representable as int, and have type int.

FYI, as of [r3937] these constants use (generated) #defines instead
of enumerations.

Thank you for pointing out this portability issue.

Regards,
Joseph Koshy

[Elftoolchain-developers] [proposal] merge with LLVM?

[Jens S. <sta...@gm...>]

Dear all,

I am using the library part of the elftoolchain together with LLVM for
my custom musl/clang based Linux OS (Aalbus), and I think this might be
a common use of this project.

Since there is a significant overlap between elftoolchain and llvm (for
example that both provide replacement utilities for binutils) and I am
guessing a significant overlap in downstream users (like FreeBSD), I
think it could be a mutually beneficial merger. Especially for you guys
since I think being under the LLVM umbrella would mean a lot more
eyeballs and mindshare.

Has this been discussed before and what are the reasons not to merge
with LLVM?

I got inspired to ask this question after reading this ClangBuiltLinux
issue:

https://github.com/ClangBuiltLinux/linux/issues/1019

[Elftoolchain-developers] Ticket #552 - addr2line fails to resolve filename/lineno

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

A patch for this issue is in FreeBSD's review system, available at
https://reviews.freebsd.org/D23782. It was started by one of the
FreeBSD Foundation's co-op students last term, and he's returned for
another internship. Mark and I are iterating on the patch in review
now; more eyes on the patch are welcome. We hope it's committable
soon.

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. <bdragon@FreeBSD.org>]

>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
  bdragon@FreeBSD.org

[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.