elftoolchain-developers — Discussion on elftoolchain development.

[Elftoolchain-developers] Ticket #379 readelf -p should accept section names

[Sunil N. <su...@su...>]

Here is an attempt to implement solution for this ticket. Tested with
limited knowledge about elf.

Index: readelf.c
===================================================================
--- readelf.c	(revision 2487)
+++ readelf.c	(working copy)
@@ -118,6 +118,7 @@
 	size_t		 sn;		/* section index */
 #define HEX_DUMP	0x0001
 #define STR_DUMP	0x0002
+	const char	 *sname;	/* section name */
 	int		 op;		/* dump op type */
 	STAILQ_ENTRY(dumpop) dumpop_list;
 };
@@ -196,6 +197,7 @@
 };
 
 static void add_dumpop(struct readelf *re, size_t sn, int op);
+static void addstr_dumpop(struct readelf *re, const char *sname, int op);
 static const char *aeabi_adv_simd_arch(uint64_t simd);
 static const char *aeabi_align_needed(uint64_t an);
 static const char *aeabi_align_preserved(uint64_t ap);
@@ -270,6 +272,7 @@
 static void dump_verneed(struct readelf *re, int dump);
 static void dump_versym(struct readelf *re);
 static struct dumpop *find_dumpop(struct readelf *re, size_t sn, int op);
+static struct dumpop *findstr_dumpop(struct readelf *re, const char *sname, int op);
 static const char *get_string(struct readelf *re, int strtab, size_t off);
 static const char *get_symbol_name(struct readelf *re, int symtab, int i);
 static uint64_t get_symbol_value(struct readelf *re, int symtab, int i);
@@ -5961,7 +5964,8 @@
 	int i, j, elferr, found;
 
 	for (i = 1; (size_t) i < re->shnum; i++) {
-		if (find_dumpop(re, (size_t) i, STR_DUMP) == NULL)
+		if ((find_dumpop(re, (size_t) i, STR_DUMP) == NULL) &&
+		    (findstr_dumpop(re, re->sl[i].name, STR_DUMP) == NULL))
 			continue;
 		s = &re->sl[i];
 		(void) elf_errno();
@@ -6314,12 +6318,28 @@
 		if ((d = malloc(sizeof(*d))) == NULL)
 			err(EXIT_FAILURE, "malloc failed");
 		d->sn = sn;
+		d->sname = NULL;
 		d->op = op;
 		STAILQ_INSERT_TAIL(&re->v_dumpop, d, dumpop_list);
 	} else
 		d->op |= op;
 }
 
+static void
+addstr_dumpop(struct readelf *re, const char *sname, int op)
+{
+	struct dumpop *d;
+
+	if ((d = findstr_dumpop(re, sname, 0)) == NULL) {
+		if ((d = malloc(sizeof(*d))) == NULL)
+			err(EXIT_FAILURE, "malloc failed");
+		d->sname = sname;
+		d->op = op;
+		STAILQ_INSERT_TAIL(&re->v_dumpop, d, dumpop_list);
+	} else
+		d->op |= op;
+}
+
 static struct dumpop *
 find_dumpop(struct readelf *re, size_t sn, int op)
 {
@@ -6333,6 +6353,19 @@
 	return (NULL);
 }
 
+static struct dumpop *
+findstr_dumpop(struct readelf *re, const char *sname, int op)
+{
+	struct dumpop *d;
+
+	STAILQ_FOREACH(d, &re->v_dumpop, dumpop_list) {
+		if ( d->sname && (strcmp(d->sname, sname) == 0) &&
+		    (op == 0 || op & d->op))
+			return (d);
+	}
+
+	return (NULL);
+}
 static struct {
 	const char *ln;
 	char sn;
@@ -6626,6 +6659,7 @@
 	struct readelf	*re, re_storage;
 	unsigned long	 sn;
 	int		 opt, i;
+	char		*ep;
 
 	re = &re_storage;
 	memset(re, 0, sizeof(*re));
@@ -6682,7 +6716,11 @@
 			break;
 		case 'p':
 			re->options |= RE_P;
-			sn = strtoul(optarg, NULL, 10);
+			sn = strtoul(optarg, &ep, 10);
+			if (optarg[0] == '\0' || *ep != '\0') {
+				addstr_dumpop(re, optarg, STR_DUMP);
+				break;
+			}
 			add_dumpop(re, (size_t) sn, STR_DUMP);
 			break;
 		case 'r':

[Elftoolchain-developers] Fix seg fault in readelf

[Sunil N. <su...@su...>]

Hello,

According to elf_getdata(3) d_buf can be NULL. This diff checks for
d_buf while doing a str_dump. This fixes a crash when dumping .bss in
readelf.

readelf -p23 readlelf

Index: readelf.c
===================================================================
--- readelf.c	(revision 2487)
+++ readelf.c	(working copy)
@@ -5972,7 +5972,7 @@
 				    elf_errmsg(elferr));
 			continue;
 		}
-		if (d->d_size <= 0)
+		if ((d->d_size <= 0) || (d->d_buf == NULL))
 			continue;
 		buf_end = (unsigned char *) d->d_buf + d->d_size;
 		start = (unsigned char *) d->d_buf;

Re: [Elftoolchain-developers] Fix compilation on OpenBSD-current and FreeBSD 9.0-Release

[Kai W. <kai...@gm...>]

On Sat, Apr 07, 2012 at 08:27:03PM +0530, Sunil Nimmagadda wrote:
> Hello,
> 
> On FreeBSD 9.0-Release -Werror causes "nm" compilation to fail without
> the braces.
> 
> Also fix compilation of "ar" on OpenBSD-current with libarchive-3.0.3.
> archive_version function changed in later versions and using
> archive_version_string is backward compatible.

Patch committed in r2484 and r2485. Thanks!

Kai

[Elftoolchain-developers] Fix compilation on OpenBSD-current and FreeBSD 9.0-Release

[Sunil N. <su...@su...>]

Hello,

On FreeBSD 9.0-Release -Werror causes "nm" compilation to fail without
the braces.

Also fix compilation of "ar" on OpenBSD-current with libarchive-3.0.3.
archive_version function changed in later versions and using
archive_version_string is backward compatible.

Index: nm/nm.c
===================================================================
--- nm/nm.c	(revision 2478)
+++ nm/nm.c	(working copy)
@@ -578,12 +578,13 @@
 	 * In non-POSIX mode, the option is a synonym for the '-A' and
 	 * '--print-file-name' options.
 	 */
-	if (oflag)
+	if (oflag) {
 		if (is_posix)
 			nm_opts.t = RADIX_OCT;
 		else
 			nm_opts.print_name = PRINT_NAME_FULL;
-
+	}
+	
 	assert(nm_opts.sort_fn != NULL && "nm_opts.sort_fn is null");
 	assert(nm_opts.elem_print_fn != NULL &&
 	    "nm_opts.elem_print_fn is null");
Index: ar/ar.c
===================================================================
--- ar/ar.c	(revision 2478)
+++ ar/ar.c	(working copy)
@@ -429,7 +429,8 @@
 static void
 bsdar_version(void)
 {
-	(void)printf("%s (%s, %s)\n", ELFTC_GETPROGNAME(), archive_version(),
+	(void)printf("%s (%s, %s)\n", ELFTC_GETPROGNAME(), archive_version_string(),
 	    elftc_version());
 	exit(EXIT_SUCCESS);
 }

Re: [Elftoolchain-developers] port to Windows

[Cherry G. M. <che...@gm...>]

On 10 March 2012 02:26, Antoine LECA <ant...@gm...> wrote:
> Hi there!
>
> I am brand new to this list, so I was not able to link properly to the
> message I am answering; I beg your pardon for the annoyance.
>
> On Feb. 26th, Joseph Koshy wrote:
>> I would like to explore we could support a Win32-compatible port
>> of the project in an ongoing way.  We have only done development on
>> POSIX/unix-like operating systems till now.
>
> Do not forget that the two things are not incompatible!
> Cygwin and SUA (Interix) are two --distinct-- ways to provide
> POSIX/unix-like environment using the Win32 binary format.
>

A third option is uwin:
http://www2.research.att.com/~gsf/download/uwin/uwin.html

-- 
~Cherry

Re: [Elftoolchain-developers] port to Windows

[Antoine L. <ant...@gm...>]

Hi there!

I am brand new to this list, so I was not able to link properly to the
message I am answering; I beg your pardon for the annoyance.

On Feb. 26th, Joseph Koshy wrote:
> I would like to explore we could support a Win32-compatible port
> of the project in an ongoing way.  We have only done development on
> POSIX/unix-like operating systems till now.

Do not forget that the two things are not incompatible!
Cygwin and SUA (Interix) are two --distinct-- ways to provide
POSIX/unix-like environment using the Win32 binary format.

SUA is particularly interesting (IMNSHO) since while it uses PE-COFF as
"storage" format, the way it links to shared objects is much more alike
ELF than to Windows DLLs.
And of course SUA, previously Interix, born OpenNT, is a genuine POSIX
environment, with very few differences from *BSD.


> The first question I would have is whether it is possible to build &
> test Windows(R)-compatible binaries using open-source and freely
> available tools:

Wine (http://www.winehq.org/) could be an alternative which would allow
you to actually test produced binaries on FOSS.

> - Would a port to use the MingW cross-toolchain be similarly
>   compatible?

Many projects, including high-profile ones, are using that solution.
As Derek remarked, when it comes to plain C, Mingw, MS Visual C++, and
several other Win32 compilers are mostly interchangeable, with debug
formats a notable exception.


Antoine

[Elftoolchain-developers] [Announce] A new version of the "libelf by Example" tutorial

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

Hello All,

A new version of the "libelf by Example" tutorial may be downloaded
from:

   http://sourceforge.net/projects/elftoolchain/files/Documentation/libelf-by-example/20120308/

In brief, the changes since the previous (2010 Nov) version are:

- The diagrams have been made clearer and made more consistent with
  the document's typography.

- All diagrams in the tutorial have been reworked to use Till Tantau's
  excellent TikZ/PGF drawing library for TeX.

- A graphical 'overview' of the tutorial has been added to the
  introduction.

- There have been a few minor changes to the text of the article
  itself.


Your comments are welcome, as ever.

Regards,
Koshy

Re: [Elftoolchain-developers] port to Windows

[Derek B. <bru...@go...>]

On Sun, Feb 26, 2012 at 12:11 AM, Joseph Koshy <jk...@us...
> wrote:

> The first question I would have is whether it is possible to build &
> test Windows(R)-compatible binaries using open-source and freely
> available tools:
>
> - Would a source tree that has been ported to ReactOS also be
>  compatible with regular Windows(R)?
>

Theoretically, yes, as ReactOS is designed to be ABI-compatible with
Windows 2003.  However, ReactOS is still "alpha".  I would expect it to be
complete enough for your purposes, though I have never run anything on top
of it myself.

- Would a port to use the MingW cross-toolchain be similarly
>  compatible?
>

I see two questions here.  First, would building elftoolchain using MinGW
gcc be sufficient, instead of using Visual Studio.  My port of elftoolchain
used the Microsoft compiler because our existing DynamoRIO and Dr. Memory
code is built with that compiler.  It would certainly be possible to
instead build efltoolchain using MinGW gcc, and that would also simplify
the porting (designated initializers, snprintf if using MinGW static libc).
 The MinGW headers do include the key PECOFF info (definitions like
IMAGE_SECTION_HEADER, etc.)  Furthermore, the resulting static or shared
libraries would even be binary compatible and linkable with the Microsoft
compiler, so this would not preclude using them with Visual Studio
projects.  However, the debug symbols would not be compatible, though that
may not be a primary concern.  By building elftoolchain with the Microsoft
compiler I was able to combine the elftoolchain debugging information into
Dr. Memory's debug info (in PDB format).  Of course this was mostly useful
while debugging my changes to elftoolchain itself and would be less
important if the elftoolchain project officially supported PECOFF.

Your second question is about cross-compiling and that should work well:
you should be able to build PECOFF files on Linux and you could even enable
PECOFF parsing support in a Linux build of elftoolchain and run some tests
on Linux.  You would still want to do testing on Windows/ReactOS itself of
course.

- Derek

Re: [Elftoolchain-developers] port to Windows

[Reid K. <rn...@go...>]

On Sun, Feb 26, 2012 at 12:11 AM, Joseph Koshy <jk...@us...
> wrote:

> > Let me know if you're interested in my port and we can discuss how to
> handle
> > the designated initializers, build system, and other issues.
>
> The first question I would have is whether it is possible to build &
> test Windows(R)-compatible binaries using open-source and freely
> available tools:
>
> - Would a source tree that has been ported to ReactOS also be
>  compatible with regular Windows(R)?
> - Would a port to use the MingW cross-toolchain be similarly
>  compatible?
>

I don't know of anyone who is attempting to test Windows apps on ReactOS,
so I assume it's not well tested.

What you could do is find a way to test the pecoff parsing on a POSIX
system, which would test the code and prevent bitrot.

However, that wouldn't guarantee compatibility with Visual Studio's
compiler.  It doesn't accept C99 features or gnu extensions like gcc.  I
think you can pass -std=c89 to gcc (or clang) to get it to behave the same.
 That won't define _MSCVER, which the current patch uses to detect Windows,
but it should guarantee compatibility for all the shared code.

The test that would most reliably guarantee compatibility is to compile and
run the code on Windows (not free) using Visual Studio Express (gratis).

Reid

Re: [Elftoolchain-developers] port to Windows

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

> I have recently compiled elftoolchain on Windows for use with the Dr. Memory
> open-source memory tool (http://code.google.com/p/drmemory/) where we need
> to obtain line number information from MinGW and Cygwin gcc-compiled
> applications.
> [..snip..]
> Let me know if you're interested in my port and we can discuss how to handle
> the designated initializers, build system, and other issues.

Thanks for sending us a heads-up about your work.

I would like to explore we could support a Win32-compatible port
of the project in an ongoing way.  We have only done development on
POSIX/unix-like operating systems till now.

The first question I would have is whether it is possible to build &
test Windows(R)-compatible binaries using open-source and freely
available tools:

- Would a source tree that has been ported to ReactOS also be
  compatible with regular Windows(R)?
- Would a port to use the MingW cross-toolchain be similarly
  compatible?

Thanks,
Koshy

Re: [Elftoolchain-developers] A truly read-write elf?

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

> I am trying to get elftoolchain to generate a read-write elf that
> actually works, however, everytime I call update(ELF_C_WRITE),
> almost all of the data structures get destroyed.

The internal data structures associated with an ELF object do get
freed on successful completion of an elf_update(ELF_C_WRITE)
operation.  Applications are required to retrieve this information
afresh from the ELF descriptor after calling elf_update(ELF_C_WRITE).

> See elf_update.cpp:_libelf_update_elf.

What is "elf_update.cpp" here?  If there was an attachment with example
code, it does not seem to have come through.

> Now, since I have a new raw elf data, how do I reconstruct the in
> memory elf data structure from the rawelf file that was returned in
> __libelf_update_elf?

I'm not sure I understand the question.

After a call to elf_update(3), you should be able to query the new
contents of the ELF object using the functions in GELF(3)/ELF(3)
API (i.e., gelf_getehdr, gelf_getphdr, elf_getscn, etc.), just as you
would for a fresh ELF descriptor.

Hope this helps.

Regards,
Koshy

[Elftoolchain-developers] A truly read-write elf?

[Villmow, M. <Mic...@am...>]

I am trying to get elftoolchain to generate a read-write elf that actually works, however, everytime I call  update(ELF_C_WRITE), almost all of the data structures get destroyed.
See elf_update.cpp:_libelf_update_elf.

Now, since I have a new raw elf data, how do I reconstruct the in memory elf data structure from the rawelf file that was returned in __libelf_update_elf?

Thanks,
Micah

[Elftoolchain-developers] port to Windows

[Derek B. <bru...@go...>]

I have recently compiled elftoolchain on Windows for use with the Dr.
Memory open-source memory tool (http://code.google.com/p/drmemory/) where
we need to obtain line number information from MinGW and Cygwin
gcc-compiled applications.

For our use I did a relatively hacky port, using a few include files from
Cygwin, and I built everything directly and did not properly set up the
Makefiles.  Are you interested in a proper port contributed back to your
sources?  There was a post to this mailing list back in 2010 about plans
for porting to Windows with a receptive response, but I did not see any
follow-up.

I built with Visual Studio 2005 and 2008 and had to undo the "designated
initializers" in the elftoolchain code that these compilers do not support,
in addition to handling the different _snprintf semantics, along with
writing new code for PECOFF to replace the ELF code.  The patch I used is
at
http://code.google.com/p/dynamorio/source/browse/trunk/ext/drsyms/libelftc-pecoff/libelftc-pecoff.patch
and my build instructions are at
http://code.google.com/p/dynamorio/source/browse/trunk/ext/drsyms/libelftc-pecoff/HOWTOBUILD.
 I also hit an issue with dwarf_srclines not being sorted which I filed as
https://sourceforge.net/apps/trac/elftoolchain/ticket/386.

Let me know if you're interested in my port and we can discuss how to
handle the designated initializers, build system, and other issues.

- Derek

[Elftoolchain-developers] ld(1) status report and my holiday traveling plan

[Kai W. <kai...@gm...>]

Hi,

I think I should give a short status update about the ld(1) on
trunk. Currently our ld(1) can:

1. Parse GNU ld(1) linker script.
2. Support a few linker script commands and expressions.
3. Parse input ELF object files.
4. Support very basic symbol resolving.
5. Support archive/dso searching.
6. Support simple output object layout.

The next status report will be around Feb/Mar 2012. Hopefully by
then we can finish:

1. ELF output generation.
2. Support for "-static" link.
3. Support for i386/amd64 relocations.

>From tomorrow, I will be traveling in China through the holidays, and
be back around Jan 4th 2012.

Thanks,
Kai

Re: [Elftoolchain-developers] Multiple archs and platforms.

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

> I played around and decided touching the code was not a great solution.
> Instead I have written a mmap/munmap pair of functions for Windows based on
> the Python code for the mmap module and I can read elf files without a
> problem on Windows. I do not know if the update code for writes works.

Just as a data point, the Minix team seems to have worked around the
lack of an mmap() system call in Minix by implementing a malloc() based
replacement:

  http://git.minix3.org/?p=minix.git;a=blob;f=lib/libelf/compat/mmap.c

Some of our tools also use mmap(); I need check whether we can use a
simple elf_begin() instead, for these cases.

Regards,
Koshy

Re: [Elftoolchain-developers] Multiple archs and platforms.

[Chris J. <ch...@rt...>]

On 23/11/11 4:18 PM, Joseph Koshy wrote:
>> I am developing a linker for the RTEMS project to support dynamic
>> loading. ... I am pleased to report there are no problems with the
>> testing I have done.
>
> That's great to know.
>

It is a nice package and seems to be working well. I plan to stress it a 
little more in the linker once I have the Windows port working.

>> You can find the RTEMS project at http://www.rtems.org/ and the linker's
>> code is: [snip]
>
> I will take a look.
>

Thanks.

>> Windows is a little more difficult to support. The couple of issues I
>> have so far are:
>
>> 1. Includes such as "#include<sys/errno.h>", and "#include
>> <sys/cdefs.h>" are not supported. I have worked around this issue with a
>> win32 specific include directory that maps to the standard headers in my
>> application.
>
> I lack clue about program development under Windows.
>

I am no expert, but given a need I will get something working. I have a 
need.

All the code compiles and builds under Windows with a small amount of 
help. This is a credit to the code base.

>> 2. There is no mmap call. I see:
>>
>>   LIBELF_F_RAWFILE_MALLOC | LIBELF_F_SPECIAL_FILE
>>
>> could be used but I am not sure about a couple of things. Does this read
>> the whole ELF file into memory ?
>
> Yes, the RAWFILE_MALLOC case will read the whole ELF object into
> memory.  The motivation for the code was to support reading of an ELF
> object from device files ("/dev/ksyms" in {Free,Net}BSD) and from
> streams (e.g., from sockets and pipes).  Such file descriptors usually
> do not support mmap() or seek(), so ELF object needs to be read in
> sequentially.
>
> One optimization for the RAWFILE_MALLOC case could be to have libelf
> read in portions of the ELF object "on demand".  That said, further
> study would be needed to determine the tradeoffs involved---IIRC the
> default layout puts the section header table at the very end of an ELF
> object, so use cases that access sections could end up reading the
> entire ELF object into memory, even if such an optmization were
> implemented.
>

I think we can avoid any need to mess with this code. See below.

>> Secondly, I really do not like the idea
>> of __WIN32__ all over the place. I can support "HAVE_CONFIG_H" and
>> "HAVE_MMAP" etc. How should I handle this ?
>
> IMHO, an ELFTC_HAVE_MMAP configuration option would be the way to go.
>

I played around and decided touching the code was not a great solution. 
Instead I have written a mmap/munmap pair of functions for Windows based 
on the Python code for the mmap module and I can read elf files without 
a problem on Windows. I do not know if the update code for writes works.

This means I can read an elf file created on MacOS using a m68k 
cross-compiler on Windows. I am happy with this. I have uploaded 
rtl-host-20111123.tar.bz2 with the Windows changes.

> FYI, I have created ticket #366 to track this item:
>
>    http://sourceforge.net/apps/trac/elftoolchain/ticket/366.
>

Thanks. Should I attach patches once I have them ?

Chris

Re: [Elftoolchain-developers] Multiple archs and platforms.

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

> I am developing a linker for the RTEMS project to support dynamic
> loading. ... I am pleased to report there are no problems with the
> testing I have done.

That's great to know.

> You can find the RTEMS project at http://www.rtems.org/ and the linker's
> code is: [snip]

I will take a look.

> Windows is a little more difficult to support. The couple of issues I
> have so far are:

> 1. Includes such as "#include <sys/errno.h>", and "#include
> <sys/cdefs.h>" are not supported. I have worked around this issue with a
> win32 specific include directory that maps to the standard headers in my
> application.

I lack clue about program development under Windows.

> 2. There is no mmap call. I see:
>
>   LIBELF_F_RAWFILE_MALLOC | LIBELF_F_SPECIAL_FILE
>
> could be used but I am not sure about a couple of things. Does this read
> the whole ELF file into memory ?

Yes, the RAWFILE_MALLOC case will read the whole ELF object into
memory.  The motivation for the code was to support reading of an ELF
object from device files ("/dev/ksyms" in {Free,Net}BSD) and from
streams (e.g., from sockets and pipes).  Such file descriptors usually
do not support mmap() or seek(), so ELF object needs to be read in
sequentially.

One optimization for the RAWFILE_MALLOC case could be to have libelf
read in portions of the ELF object "on demand".  That said, further
study would be needed to determine the tradeoffs involved---IIRC the
default layout puts the section header table at the very end of an ELF
object, so use cases that access sections could end up reading the
entire ELF object into memory, even if such an optmization were
implemented.

> Secondly, I really do not like the idea
> of __WIN32__ all over the place. I can support "HAVE_CONFIG_H" and
> "HAVE_MMAP" etc. How should I handle this ?

IMHO, an ELFTC_HAVE_MMAP configuration option would be the way to go.

FYI, I have created ticket #366 to track this item:

  http://sourceforge.net/apps/trac/elftoolchain/ticket/366.

Regards,
Koshy

[Elftoolchain-developers] Multiple archs and platforms.

[Chris J. <ch...@rt...>]

Hello,

I am developing a linker for the RTEMS project to support dynamic 
loading. I have just switched from the GPL libelf to your libelf after 
taking a look in the FreeBSD kernel. I am pleased to report there are no 
problems with the testing I have done. Our use of libelf is fairly basic.

You can find the RTEMS project at http://www.rtems.org/ and the linker's 
code is:

 
http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtl-host-20111121.tar.bz2

To build install waf and then 'waf configure build'.

I plan to submit clean patches once I have the work completed.

I have copied in just the libelf and common directories. The code is 
built using waf and I can currently build on Linux (CentOS5), MacOS 
(Snow Leopard) and FreeBSD (v9). Windows is a work in progress and the 
reason for the post.

Some background. RTEMS supports around 12 architectures and all are ELF 
based. We need something to play with ELF files at a container level. 
The linker uses files, sections, and symbols and not much else. The low 
level target specific code is located in RTEMS and runs on the target 
hardware. So far I can handle SPARC, M68K and i386 ELF files on MacOS 
with the same executable. I do not expect problems in the other host 
operating systems.

Windows is a little more difficult to support. The couple of issues I 
have so far are:

1. Includes such as "#include <sys/errno.h>", and "#include 
<sys/cdefs.h>" are not supported. I have worked around this issue with a 
win32 specific include directory that maps to the standard headers in my 
application.

2. There is no mmap call. I see:

   LIBELF_F_RAWFILE_MALLOC | LIBELF_F_SPECIAL_FILE

could be used but I am not sure about a couple of things. Does this read 
the whole ELF file into memory ? Secondly, I really do not like the idea 
of __WIN32__ all over the place. I can support "HAVE_CONFIG_H" and 
"HAVE_MMAP" etc. How should I handle this ?

Any guidance or suggestions would be most welcome.

Chris

[Elftoolchain-developers] v0.5.1 has been released

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

Hello All,

FYI, version 0.5.1 has been released, and may be downloaded from the
SF.NET file release system:

    http://sourceforge.net/projects/elftoolchain/files/Sources/elftoolchain-0.5.1/

Regards,
Koshy

Re: [Elftoolchain-developers] [Headsup] Branching v0.5

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

jk> It is time to branch our source tree, in preparation for the upcoming
jk> v0.5 release.

kw> I have some more nm(1) cleanup patches to commit. But I guess it's ok
kw> if we commit/merge it after branching.

Thanks.

The development branch (`trunk/`) has been branched today, to
`branches/release-branch-0.5`.  The first release on this branch will
most likely be tagged `release-0.5.1`.

This first release will comprise 14 utilities, 2 libraries, 6 test
suites, 186 manual pages and one tutorial.  The plan is to make a
"source-only" release.

A big thank-you to everyone for their hard work in bringing the
project to this milestone.

Regards,
Koshy

Re: [Elftoolchain-developers] [Headsup] Branching v0.5

[Kai W. <kai...@gm...>]

On Tue, Nov 08, 2011 at 10:49:18AM +0530, Joseph Koshy wrote:
> Hello All,
> 
> It is time to branch our source tree, in preparation for the upcoming
> v0.5 release.

Great!

> Our source tree has been stable and passing its tests for the past few
> weeks.  If you have pending work that would require the creation of
> the branch in SVN to be deferred, please do let me know (and please
> also create a ticket in Trac associated with the RELEASE_0_5 milestone
> for tracking your task).
> 
> Otherwise, I plan to create the branch in SVN within a day or so.
> 
> After the branch has been created development work can continue in
> trunk/, with controlled merges of changes from trunk to the release
> branch as and when needed.

I have some more nm(1) cleanup patches to commit. But I guess it's ok
if we commit/merge it after branching.

Kai

[Elftoolchain-developers] [Headsup] Branching v0.5

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

Hello All,

It is time to branch our source tree, in preparation for the upcoming
v0.5 release.

Our source tree has been stable and passing its tests for the past few
weeks.  If you have pending work that would require the creation of
the branch in SVN to be deferred, please do let me know (and please
also create a ticket in Trac associated with the RELEASE_0_5 milestone
for tracking your task).

Otherwise, I plan to create the branch in SVN within a day or so.

After the branch has been created development work can continue in
trunk/, with controlled merges of changes from trunk to the release
branch as and when needed.

Regards,
Koshy

Re: [Elftoolchain-developers] Support for "in-place" updates to ELF objects has been added to libelf

[Eric S. <sch...@gm...>]

Joseph Koshy <jk...@us...> writes:

>>  $ ./extend-a-section hello
>>  fstat() failed: "Bad address".
>>  Size error: expected=118, elf_update()=6536
>
>> I imagine that I broke something while replacing the TC_* macros
>> with C code.  I apologize for asking such a simple question, but
>> would you mind taking a look to see if the error is obvious to you.
>
> 1) The stat() call at line 46 appears to be failing because argv[2]
>    was not supplied.
>
> File "extend-a-section.c":
>
>     21	  struct stat sb;
>     ...
>     25	  const char *srcfile = argv[1];
>     26	  const char *reffile = argv[2];
>     ...
>     46	  if (stat(reffile, &sb) < 0) {
>     47	    printf("fstat() failed: \"%s\".\n", strerror(errno));
>     48	  }
>
> The value of the "sb.st_size" field would be undefined, and this
> then leads to the failure further down.
>
>     ...
>     64	  if (fsz1 != sb.st_size) {
>     65	    printf("Size error: expected=%ld, elf_update()=%ld\n",
> sb.st_size, fsz1);
>     66	  }
>
>
> You could remove these file size checks---they are only relevant for test code.
>
> 2) If your code is changing an ELF executable, it would also need to
>    adjust the ELF program header to match the new layout of the file's
>    content---in the ELF(3) API, the contents of the PHDR table are
>    managed by the application, not libelf.
>
> Regards,
> Koshy

Thank you for the advice.

I am now able to read, modify and write an elf file without
corruption.

Specifically, using the attached script I can change the last byte the
.text section (a padding byte which is of no consequence) of a hello
world file.  I can then write the modified file out to disk resulting in
a new valid elf file which is different from the original but still
executes successfully.

Thanks for the help -- Eric

Re: [Elftoolchain-developers] Support for "in-place" updates to ELF objects has been added to libelf

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

>  $ ./extend-a-section hello
>  fstat() failed: "Bad address".
>  Size error: expected=118, elf_update()=6536

> I imagine that I broke something while replacing the TC_* macros
> with C code.  I apologize for asking such a simple question, but
> would you mind taking a look to see if the error is obvious to you.

1) The stat() call at line 46 appears to be failing because argv[2]
   was not supplied.

File "extend-a-section.c":

    21	  struct stat sb;
    ...
    25	  const char *srcfile = argv[1];
    26	  const char *reffile = argv[2];
    ...
    46	  if (stat(reffile, &sb) < 0) {
    47	    printf("fstat() failed: \"%s\".\n", strerror(errno));
    48	  }

The value of the "sb.st_size" field would be undefined, and this
then leads to the failure further down.

    ...
    64	  if (fsz1 != sb.st_size) {
    65	    printf("Size error: expected=%ld, elf_update()=%ld\n",
sb.st_size, fsz1);
    66	  }


You could remove these file size checks---they are only relevant for test code.

2) If your code is changing an ELF executable, it would also need to
   adjust the ELF program header to match the new layout of the file's
   content---in the ELF(3) API, the contents of the PHDR table are
   managed by the application, not libelf.

Regards,
Koshy

Re: [Elftoolchain-developers] Support for "in-place" updates to ELF objects has been added to libelf

[Eric S. <sch...@gm...>]

Eric Schulte <sch...@gm...> writes:

> Joseph Koshy <jk...@us...> writes:
>
>> e.s> Would it be possible to share a simple C script which opens, edits and
>> e.s> then writes out a modified elf file using libelf?
>>
>> There are a few such examples in libelf's test suite; please look for
>> the constant "ELF_C_RDWR" in:
>>
>>     http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/test/libelf/tset/elf_update/update.m4
>>
>
> Thanks for the pointer.  Attached is my attempt to re-write one of the
> test cases into an external C file to allow extending a data section in
> an existing elf file.  The resulting script fails with the following...
>
>   $ ./extend-a-section hello
>   fstat() failed: "Bad address".
>   Size error: expected=118, elf_update()=6536
>
> I imagine that I broke something while replacing the TC_* macros with C
> code.  I apologize for asking such a simple question, but would you mind
> taking a look to see if the error is obvious to you.
>

Along the same lines the following script reads an elf file and then
writes it back out without making any changes.  Despite running
successfully and throwing no errors the resulting re-written file does
segfaults.