elftoolchain-developers — Discussion on elftoolchain development.

Re: [Elftoolchain-developers] Unable to write-out changes in existing ELF file

[Nikhil M. <mit...@gm...>]

Hi,
My program does not give any errors and the program is executed till the
end.
But the ELF file given as an argument to my program is not modified.
In other words, the ELF file should have been modified after my program adds
a new section into the ELF file.
The argument file I created is a simple "Hello World" c program. I have
verified the necessary file permissions too.
Here is the complete program:
-------------------------------------------------
int
main (int argc , char ** argv)
{
  int i, fd;
  Elf* e;
  char* k, id, name;
  Elf_Kind ek;
  Elf32_Ehdr ehdr;
  Elf_Scn* scn;
  Elf_Data* data;
  Elf32_Shdr* shdr;
  size_t sh_size;
  int sh_num;
  uint32_t hash_words[] =
  {
    0x01234567
  };

  if (argc != 2)
  {
    errx(EX_USAGE , "usage: %s filename", argv[0]);
  }

  if (elf_version(EV_CURRENT) == EV_NONE)
  {
    errx(EX_SOFTWARE, "ELF library initialization failed : %s",
elf_errmsg(-1));
  }
  printf("\n ELF Version : %d\n", EV_CURRENT);

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

  if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
  {
    errx(EX_SOFTWARE , "elf_begin() failed : %s .", elf_errmsg(-1));
  }
  ek = elf_kind(e);

 switch (ek)
   {
   case ELF_K_AR :
        k = "ar (1) archive" ;
        break ;
   case ELF_K_ELF :
        k = "elf object" ;
        break ;
   case ELF_K_NONE :
        k = "data" ;
        break ;
   default :
        k = "unrecognized" ;
   }
  printf("%s : %s \n", argv [1], k);
  if (elf32_getehdr(e) == NULL )
  {
    errx(EX_SOFTWARE, " getehdr () failed : %s . ", elf_errmsg(-1));
  }

  scn = NULL;
  if((scn = elf_newscn(e)) == NULL)
  {
    errx(EX_SOFTWARE , " newscn () failed : %s . ", elf_errmsg(-1));
  }

  if((data = elf_newdata(scn)) == NULL)
  {
    errx(EX_SOFTWARE , " newdata () failed : %s . ", elf_errmsg(-1));
  }
  data->d_align = 4;
  data->d_off = 0LL;
  data->d_buf = hash_words;
  data->d_type = ELF_T_WORD;
  data->d_size = sizeof(hash_words);
  data->d_version = EV_CURRENT;

 if((shdr = elf32_getshdr(scn)) == NULL)
  {
    errx(EX_SOFTWARE , " elf32_getshdr () failed : %s . ", elf_errmsg(-1));
  }

  shdr->sh_name = 9999;
  shdr->sh_type = SHT_HASH;
  shdr->sh_flags = SHF_ALLOC;
  shdr->sh_entsize = 0;

  if (elf_update(e, ELF_C_NULL) < 0)
  {
    errx(EX_SOFTWARE , " elf_update () 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(EX_SOFTWARE , " elf_update () failed : %s . ", elf_errmsg(-1));
  }

  elf_end(e);
  close(fd);
  exit(EX_OK);
}
--------------------------------------------------------------------------------------------------
- Nikhil


On Sat, Aug 7, 2010 at 1:02 PM, Joseph Koshy
<jk...@us...>wrote:

> > Based on tutorial at "http://sourceforge.net/apps/trac/elftoolchain/"
> > I wrote a program to create a new section into an existing ELF file.
>
> > My program is not writing out the changes into the ELF file.
>
> > Here is the snippet starting from the creation of new section till end of
> > file:
>
> [snip]
>
> >   if (elf_update(e, ELF_C_WRITE) < 0)
> >   {
> >     errx(EX_SOFTWARE , " elf_update () failed : %s . ", elf_errmsg(-1));
> >   }
>
> There isn't enough information in your post to formulate a useful
> reply.  For example, your post does not indicate where precisely your
> program fails, and what the error message at that point is.
>
> I personally have found the following article to be a good guide to
> framing questions:
>
>   http://catb.org/esr/faqs/smart-questions.html
>
> Koshy
>

Re: [Elftoolchain-developers] Unable to write-out changes in existing ELF file

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

> Based on tutorial at "http://sourceforge.net/apps/trac/elftoolchain/"
> I wrote a program to create a new section into an existing ELF file.

> My program is not writing out the changes into the ELF file.

> Here is the snippet starting from the creation of new section till end of
> file:

[snip]

>   if (elf_update(e, ELF_C_WRITE) < 0)
>   {
>     errx(EX_SOFTWARE , " elf_update () failed : %s . ", elf_errmsg(-1));
>   }

There isn't enough information in your post to formulate a useful
reply.  For example, your post does not indicate where precisely your
program fails, and what the error message at that point is.

I personally have found the following article to be a good guide to
framing questions:

   http://catb.org/esr/faqs/smart-questions.html

Koshy

[Elftoolchain-developers] Unable to write-out changes in existing ELF file

[Nikhil M. <mit...@gm...>]

Hi,
Based on tutorial at "http://sourceforge.net/apps/trac/elftoolchain/"
I wrote a program to create a new section into an existing ELF file.
My program is not writing out the changes into the ELF file.
Here is the snippet starting from the creation of new section till end of
file:
--------------------------------------------------------------------------------------------------------------------
  scn = NULL;
  if((scn = elf_newscn(e)) == NULL)
  {
    errx(EX_SOFTWARE , " newscn () failed : %s . ", elf_errmsg(-1));
  }

  if((data = elf_newdata(scn)) == NULL)
  {
    errx(EX_SOFTWARE , " newdata () failed : %s . ", elf_errmsg(-1));
  }
  data->d_align = 4;
  data->d_off = 0LL;
  data->d_buf = hash_words;
  data->d_type = ELF_T_WORD;
  data->d_size = sizeof(hash_words);
  data->d_version = EV_CURRENT;

  if((shdr = elf32_getshdr(scn)) == NULL)
  {
    errx(EX_SOFTWARE , " elf32_getshdr () failed : %s . ", elf_errmsg(-1));
  }

  shdr->sh_name = 9999;
  shdr->sh_type = SHT_HASH;
  shdr->sh_flags = SHF_ALLOC;
  shdr->sh_entsize = 0;

  if (elf_update(e, ELF_C_NULL) < 0)
  {
    errx(EX_SOFTWARE , " elf_update () 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(EX_SOFTWARE , " elf_update () failed : %s . ", elf_errmsg(-1));
  }

  elf_end(e);
  close(fd);
  exit(EX_OK);
--------------------------------------------------------------------------------
Thanks,
- Nikhil

Re: [Elftoolchain-developers] libelf and cross-platform portability

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

> the first time I looked at libelf, it didn't work on NetBSD due to
> various macros and types missing from NetBSD's elf.h. This has been

Recent trees should work on NetBSD 5 though.

> This brings me to my question of whether this is really the best
> approach. Wouldn't it be much easier if libelf provide its own elf.h
> replacement with predictable content based on the libelf version and
> nothing else? This would also make it easier to use ELF (and DWARF) as
> intermediate formats for compiler and other toolchain stuff.

This is on the cards (ticket #265) and will be done before we make our
first release.

On the topic of NetBSD, we also need to setup an automated build/test
tool to periodically build the source tree and run regression tests on
NetBSD.  Is there an existing facility (perhaps a buildbot farm?)
that we could use?

Koshy

Re: [Elftoolchain-developers] libelf and cross-platform portability

[Joerg S. <jo...@br...>]

On Tue, Jul 20, 2010 at 12:34:03AM +0200, Kai Wang wrote:
> On Tue, Jul 20, 2010 at 12:15:31AM +0200, Joerg Sonnenberger wrote:
> > Hi all,
> > the first time I looked at libelf, it didn't work on NetBSD due to
> > various macros and types missing from NetBSD's elf.h. This has been
> > addressed in the mean time by adding another bunch of #if's. The same
> > applies for FreeBSD. When people want to use libelf on Solaris or Linux,
> > I expect it to grow another set of conditionals.
> 
> That's strange. We already have a bunch of #if's for NetBSD. You meant
> we need more to make it compile?

Those have been added in the mean time.

> > This brings me to my question of whether this is really the best
> > approach. Wouldn't it be much easier if libelf provide its own elf.h
> > replacement with predictable content based on the libelf version and
> > nothing else? This would also make it easier to use ELF (and DWARF) as
> > intermediate formats for compiler and other toolchain stuff.
> 
> You are right. We've thought about this as well and we're going to create
> our own ELF include files (including arch specific ELF definitions),
> similar with Binutils' include dir, I guess. However some #if's will still
> be necessary.

What conditionals should be needed? The only glaring conditional is for
strlcpy support.

Joerg

Re: [Elftoolchain-developers] libelf and cross-platform portability

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

On Tue, Jul 20, 2010 at 12:15:31AM +0200, Joerg Sonnenberger wrote:
> Hi all,
> the first time I looked at libelf, it didn't work on NetBSD due to
> various macros and types missing from NetBSD's elf.h. This has been
> addressed in the mean time by adding another bunch of #if's. The same
> applies for FreeBSD. When people want to use libelf on Solaris or Linux,
> I expect it to grow another set of conditionals.

That's strange. We already have a bunch of #if's for NetBSD. You meant
we need more to make it compile?

> This brings me to my question of whether this is really the best
> approach. Wouldn't it be much easier if libelf provide its own elf.h
> replacement with predictable content based on the libelf version and
> nothing else? This would also make it easier to use ELF (and DWARF) as
> intermediate formats for compiler and other toolchain stuff.

You are right. We've thought about this as well and we're going to create
our own ELF include files (including arch specific ELF definitions),
similar with Binutils' include dir, I guess. However some #if's will still
be necessary.

Kai

[Elftoolchain-developers] libelf and cross-platform portability

[Joerg S. <jo...@br...>]

Hi all,
the first time I looked at libelf, it didn't work on NetBSD due to
various macros and types missing from NetBSD's elf.h. This has been
addressed in the mean time by adding another bunch of #if's. The same
applies for FreeBSD. When people want to use libelf on Solaris or Linux,
I expect it to grow another set of conditionals.

This brings me to my question of whether this is really the best
approach. Wouldn't it be much easier if libelf provide its own elf.h
replacement with predictable content based on the libelf version and
nothing else? This would also make it easier to use ELF (and DWARF) as
intermediate formats for compiler and other toolchain stuff.

Joerg

Re: [Elftoolchain-developers] elf toolchain release

[Steve K. <sg...@tr...>]

On Sat, Jun 12, 2010 at 03:31:50PM +0530, Cherry G. Mathew wrote:
> On 12 June 2010 12:35, Joseph Koshy <jk...@us...> wrote:
> > c.g.m> I'm wondering if the elf toolchain has any recommended "stable"
> > c.g.m> releases that I can use to package it up for pkgsrc-wip.sf.net ?
> >
> > We haven't done a formal release yet.
> >
> > Would you be ok with a regular (say, monthly) snapshot of the toolchain source?
> >
> 
> For downstream (pkgsrc) it doesn't really matter, as long as it works
> (ie; dependencies are not outdated, builds and runs). I don't expect
> to pull it up to the "latest" on a monthly basis.
> 

If compatibility with other implementations of libelf
is important or a requirement, be aware that elftoolchain's
libelf has some issues.

http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html

-- 
Steve

Re: [Elftoolchain-developers] elf toolchain release

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

On 12 June 2010 12:35, Joseph Koshy <jk...@us...> wrote:
> c.g.m> I'm wondering if the elf toolchain has any recommended "stable"
> c.g.m> releases that I can use to package it up for pkgsrc-wip.sf.net ?
>
> We haven't done a formal release yet.
>
> Would you be ok with a regular (say, monthly) snapshot of the toolchain source?
>

For downstream (pkgsrc) it doesn't really matter, as long as it works
(ie; dependencies are not outdated, builds and runs). I don't expect
to pull it up to the "latest" on a monthly basis.

-- 
~Cherry

Re: [Elftoolchain-developers] elf toolchain release

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

c.g.m> I'm wondering if the elf toolchain has any recommended "stable"
c.g.m> releases that I can use to package it up for pkgsrc-wip.sf.net ?

We haven't done a formal release yet.

Would you be ok with a regular (say, monthly) snapshot of the toolchain source?

Koshy

[Elftoolchain-developers] elf toolchain release

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

Hello,

I'm wondering if the elf toolchain has any recommended "stable"
releases that I can use to package it up for pkgsrc-wip.sf.net ?

Cheers,
-- 
~Cherry

Re: [Elftoolchain-developers] libelftc does not build due to missing ...

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

> definition of size_t.

Patch applied, thanks!

> The program in the commented out subdirectory doe not build due to a
> missing -I to the libelf.h file.

Yes, we need to fix the test suite's build process to pick up
libraries and headers from the development tree rather than the
installed versions on the system.

Koshy

[Elftoolchain-developers] libelftc does not build due to missing ...

[Steve K. <sg...@tr...>]

definition of size_t.

--  
Steve

Index: libelftc/libelftc_vstr.c
===================================================================
--- libelftc/libelftc_vstr.c	(revision 892)
+++ libelftc/libelftc_vstr.c	(working copy)
@@ -24,6 +24,7 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include <sys/types.h>
 #include <assert.h>
 #include <libelftc.h>
 #include <stdio.h>
Index: libelftc/libelftc_dem_gnu2.c
===================================================================
--- libelftc/libelftc_dem_gnu2.c	(revision 892)
+++ libelftc/libelftc_dem_gnu2.c	(working copy)
@@ -24,6 +24,7 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include <sys/types.h>
 #include <assert.h>
 #include <ctype.h>
 #include <errno.h>
Index: libelftc/libelftc_dem_gnu3.c
===================================================================
--- libelftc/libelftc_dem_gnu3.c	(revision 892)
+++ libelftc/libelftc_dem_gnu3.c	(working copy)
@@ -23,7 +23,7 @@
  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
-
+#include <sys/types.h>
 #include <assert.h>
 #include <ctype.h>
 #include <errno.h>
Index: libelftc/libelftc_dem_arm.c
===================================================================
--- libelftc/libelftc_dem_arm.c	(revision 892)
+++ libelftc/libelftc_dem_arm.c	(working copy)
@@ -24,6 +24,7 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include <sys/types.h>
 #include <assert.h>
 #include <ctype.h>
 #include <errno.h>

[Elftoolchain-developers] Testsuite program does not build.

[Steve K. <sg...@tr...>]

The program in the commented out subdirectory
doe not build due to a missing -I to the libelf.h
file.

-- 
Steve

Index: tset/Makefile
===================================================================
--- tset/Makefile	(revision 892)
+++ tset/Makefile	(working copy)
@@ -10,7 +10,7 @@ SUBDIR+=	elf_end
 SUBDIR+=	elf_errmsg
 SUBDIR+=	elf_errno
 SUBDIR+=	elf_fill
-SUBDIR+=	elf_flagarhdr
+#SUBDIR+=	elf_flagarhdr
 SUBDIR+=	elf_flagdata
 SUBDIR+=	elf_flagehdr
 SUBDIR+=	elf_flagelf

[Elftoolchain-developers] Updating Version.map

[Steve K. <sg...@tr...>]

Seems that the addition of functions to libelf 
has gone unnoted in Version.map.  

-- 
Steve

Index: Version.map
===================================================================
--- Version.map	(revision 892)
+++ Version.map	(working copy)
@@ -91,6 +91,12 @@ local:
 	*;
 };
 
+FBSD_1.1 {
+	elf_getphdrnum;
+	elf_getshdrnum;
+	elf_getshdrstrndx;
+};
+
 /*
  * Private symbols, mostly test hooks
  */

Re: [Elftoolchain-developers] strange behaviour of elf_update()

[Luca P. <luc...@gm...>]

Hi Kay,

I've tried the patch and it works fine!

Thank you very much!

Best regards,

Luca



On Tue, Mar 2, 2010 at 2:34 PM, Kai Wang <kai...@gm...> wrote:
> Hi Luca,
>
> On Tue, Mar 02, 2010 at 02:12:31PM +0100, Luca Pizzamiglio wrote:
>> Hi to all.
>> I'm Luca and I'm using libelf on FreeBSD 7.3 to develop a tool that
>> manipulate ELF binaries. I hope that mailing list is right to post
>> this problem.
>>
>> My tool changes some information in the dynamic symbol table (using
>> gelf_update_sym()), save the elf and quit.
>>
>> elf_update(e, ELF_C_WRITE) fails with a DATA class error (Invalid data
>> buffer descriptor).
>>
>> Investigations revealed that _libelf_xlate() fails because src->d_buf is NULL.
>> Further investigations revealed that the caller function
>> _libelf_write_elf() when wants to write the program header table, use
>> the e_phdr32 field of the _Elf struct. Seems that this field is not
>> correctly initialized.
>> As workaround I call gelf_getphdr() and the problem goes away.
>
> Thanks for reporting this problem.
>
> It should be already fixed by elftoolchain svn repository revsion 305.
> However it's not yet been merged back to FreeBSD.
>
> You can fetch the diff (try svn diff -c305 in trunk/libelf) and apply
> it to the libelf in FreeBSD 7.3.
>
> Cheers,
> Kai
>

Re: [Elftoolchain-developers] strange behaviour of elf_update()

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

Hi Luca,

On Tue, Mar 02, 2010 at 02:12:31PM +0100, Luca Pizzamiglio wrote:
> Hi to all.
> I'm Luca and I'm using libelf on FreeBSD 7.3 to develop a tool that
> manipulate ELF binaries. I hope that mailing list is right to post
> this problem.
> 
> My tool changes some information in the dynamic symbol table (using
> gelf_update_sym()), save the elf and quit.
> 
> elf_update(e, ELF_C_WRITE) fails with a DATA class error (Invalid data
> buffer descriptor).
> 
> Investigations revealed that _libelf_xlate() fails because src->d_buf is NULL.
> Further investigations revealed that the caller function
> _libelf_write_elf() when wants to write the program header table, use
> the e_phdr32 field of the _Elf struct. Seems that this field is not
> correctly initialized.
> As workaround I call gelf_getphdr() and the problem goes away.

Thanks for reporting this problem.

It should be already fixed by elftoolchain svn repository revsion 305.
However it's not yet been merged back to FreeBSD.

You can fetch the diff (try svn diff -c305 in trunk/libelf) and apply
it to the libelf in FreeBSD 7.3.

Cheers,
Kai

[Elftoolchain-developers] strange behaviour of elf_update()

[Luca P. <luc...@gm...>]

Hi to all.
I'm Luca and I'm using libelf on FreeBSD 7.3 to develop a tool that
manipulate ELF binaries. I hope that mailing list is right to post
this problem.

My tool changes some information in the dynamic symbol table (using
gelf_update_sym()), save the elf and quit.

elf_update(e, ELF_C_WRITE) fails with a DATA class error (Invalid data
buffer descriptor).

Investigations revealed that _libelf_xlate() fails because src->d_buf is NULL.
Further investigations revealed that the caller function
_libelf_write_elf() when wants to write the program header table, use
the e_phdr32 field of the _Elf struct. Seems that this field is not
correctly initialized.
As workaround I call gelf_getphdr() and the problem goes away.

I attach a very simple test that shows (and solve with -DWORKAROUND)
the problem.

Is this the right behavior of the library (and I need to read the
tutorial more deeply) or I've found an unlikely bug?
I've checked the source of libelf and _libelf_getphdr() (c)allocate
the phdr in _Elf struct. May be it has to be called by elf_begin()?
Have I to open a PR?

Thanks in advance

Luca


PS: In the tutorial (libelf-by-example-20100112), I've found some
errors in the Listing 3.1 (Program 2):
the functions elf_getshdrnum(), elf_getshdrstrndx() and elf_phdrnum()
doesn't exist. The right names are: elf_getshnum(), elf_getshstrndx()
and elf_phdrnum().
PS2: I like this topic and should be great if you need help and I
could be a little involved in this project!

Re: [Elftoolchain-developers] A safe way to re-build a string table ..

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

On Tue, Feb 23, 2010 at 04:46:04PM +0100, Jay Vaughan wrote:
> Hi Kai - thanks for responding ..
> 
> > First of all I think you are posting to the wrong mailling list...
> >
> 
> Ah, I perhaps should be on elfutils-developers?  I don't mind either way, I just need some
> ELF expert(s) who are willing to talk about this stuff .. ;)  Been winging it on my own on
> this development lately, so its just good to know people who know ELF.  Please feel free
> to tell me to sod off if this is not topical for this list, though. :)

I suggest you post this to elfutils mailing list as well, may be you
can get some answers from there...

> > Second, for your problem: If this .note.MD5 (for example) section does
> > not need to be presented to the runtime loader or used during runtime,
> > you don't need to roll your own tool and you can just use objcopy(1)
> > to handle it:
> 
> It does need to be readable during runtime and the loader in our internal system is going
> to be expected to use this information along with other online services and dynamic loader
> paths, so I'd really like to not use objcopy if it means it will produce a more 'standard
> ELF Note' to write an app to do it.

Then in that case, objcopy won't work. objcopy can only add
"un-loadable" ELF sections.

> > 
> > 1. Calculate the checksum or other stuff of the ELF, construct the Elf Notes
> >    and then write all the bits to a temporary file, say '/tmp/foo'.
> > 2. Execute objcopy to add a .note.MD5 section to the ELF file:
> >    objcopy --add-section '.note.MD5=/tmp/foo' your_executable
> >   (objcopy will handle all the string table, section table headers stuff etc)
> 
> One thing this method doesn't do is properly update the name/namesz and type fields, I
> have found (correct me if I'm wrong) - so for my purposes it appears that the objcopy
> technique will not produce an *entirely* valid (to-spec) NOTE record.  What I am doing is
> using a struct like this in my elfnoter application:
> 
> #define INTW1X_ELF_SECTION      ".note.MD5"
> #define ELF_TEXT_NAME           ".text"
> 
> #define INTW1X_MD5_NOTE_NAME    "w1x_md5"
> #define INTW1X_MD5_TYPE         1
> 
> #define MD5_DESC "deadbeefd00df00ddeadbeefd00df00d"
> #define MD5_BUF_LEN 33
> 
> const struct intw1x_elf_note_md5 local_elf_note_md5
>      __attribute__ ((section(INTW1X_ELF_SECTION))) =
> {
>      .elf_note = {
>      	.n_namesz = sizeof(INTW1X_MD5_NOTE_NAME),
> 	.n_descsz = MD5_BUF_LEN,
> 	.n_type = INTW1X_MD5_TYPE
>      },
>      .name = INTW1X_MD5_NOTE_NAME,
>      .desc = MD5_DESC
> };
> 
> .. then, locating this ELF record internally within my elfnoter app programmatically, and
> 'injecting' it into the target executable after the md5 string is updated, so that I
> produce an entirely valid (all fields correct) record in the destination binary.  At least
> the thinking is that inlining the definition of this record means that the final object is
> going to be as standard as gcc is going to make it and thus all I have to do is modify the
> string and glom the object onto my target ELF binary.  This is working, its just a little
> delicate when it comes to updating the string table, alas.

You approach here looks fine to me. I don't know about elfutils libelf
and libebl, I just have general suggestion here:

1. string table (.shstrtab) create-new/destroy-old process is neccessary
   and safer.
2. make sure you also updated section header table, but I guess libebl
   has already done this for you?
3. since you're adding a "loadable" section, you need to update some entry
   in the program header (Elf_Phdr) to include the .note.MD5 section
   you added. Also you probably should insert .note.MD5 section at the end
   of the loadable sections but before ".bss" to avoid relocating ".text" and
   ".data" etc. I suppose you've already handled this since your tool is working.

> If there is a way to get objcopy to do this work, I'd love to know .. perhaps it would be
> worthwhile investigating this further and adding code to objcopy for NOTE objects, but
> then again I don't know enough about this to say for sure and I appreciate your feedback.

Binutils is lot messier than elfutils, so building your own tool using
elfutils is probably much easier than extending objcopy I guess.

Kai

Re: [Elftoolchain-developers] A safe way to re-build a string table ..

[Jay V. <jay...@th...>]

Hi Kai - thanks for responding ..

> First of all I think you are posting to the wrong mailling list...
>

Ah, I perhaps should be on elfutils-developers?  I don't mind either way, I just need some
ELF expert(s) who are willing to talk about this stuff .. ;)  Been winging it on my own on
this development lately, so its just good to know people who know ELF.  Please feel free
to tell me to sod off if this is not topical for this list, though. :)

> Second, for your problem: If this .note.MD5 (for example) section does
> not need to be presented to the runtime loader or used during runtime,
> you don't need to roll your own tool and you can just use objcopy(1)
> to handle it:

It does need to be readable during runtime and the loader in our internal system is going
to be expected to use this information along with other online services and dynamic loader
paths, so I'd really like to not use objcopy if it means it will produce a more 'standard
ELF Note' to write an app to do it.

> 
> 1. Calculate the checksum or other stuff of the ELF, construct the Elf Notes
>    and then write all the bits to a temporary file, say '/tmp/foo'.
> 2. Execute objcopy to add a .note.MD5 section to the ELF file:
>    objcopy --add-section '.note.MD5=/tmp/foo' your_executable
>   (objcopy will handle all the string table, section table headers stuff etc)

One thing this method doesn't do is properly update the name/namesz and type fields, I
have found (correct me if I'm wrong) - so for my purposes it appears that the objcopy
technique will not produce an *entirely* valid (to-spec) NOTE record.  What I am doing is
using a struct like this in my elfnoter application:

#define INTW1X_ELF_SECTION      ".note.MD5"
#define ELF_TEXT_NAME           ".text"

#define INTW1X_MD5_NOTE_NAME    "w1x_md5"
#define INTW1X_MD5_TYPE         1

#define MD5_DESC "deadbeefd00df00ddeadbeefd00df00d"
#define MD5_BUF_LEN 33

const struct intw1x_elf_note_md5 local_elf_note_md5
     __attribute__ ((section(INTW1X_ELF_SECTION))) =
{
     .elf_note = {
     	.n_namesz = sizeof(INTW1X_MD5_NOTE_NAME),
	.n_descsz = MD5_BUF_LEN,
	.n_type = INTW1X_MD5_TYPE
     },
     .name = INTW1X_MD5_NOTE_NAME,
     .desc = MD5_DESC
};

.. then, locating this ELF record internally within my elfnoter app programmatically, and
'injecting' it into the target executable after the md5 string is updated, so that I
produce an entirely valid (all fields correct) record in the destination binary.  At least
the thinking is that inlining the definition of this record means that the final object is
going to be as standard as gcc is going to make it and thus all I have to do is modify the
string and glom the object onto my target ELF binary.  This is working, its just a little
delicate when it comes to updating the string table, alas.

If there is a way to get objcopy to do this work, I'd love to know .. perhaps it would be
worthwhile investigating this further and adding code to objcopy for NOTE objects, but
then again I don't know enough about this to say for sure and I appreciate your feedback.

-- 
;
--
Jay Vaughan
jay...@in...

Re: [Elftoolchain-developers] A safe way to re-build a string table ..

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

Hi Jay, 

First of all I think you are posting to the wrong mailling list...

Second, for your problem: If this .note.MD5 (for example) section does
not need to be presented to the runtime loader or used during runtime,
you don't need to roll your own tool and you can just use objcopy(1)
to handle it:

1. Calculate the checksum or other stuff of the ELF, construct the Elf Notes
   and then write all the bits to a temporary file, say '/tmp/foo'.
2. Execute objcopy to add a .note.MD5 section to the ELF file:
   objcopy --add-section '.note.MD5=/tmp/foo' your_executable
  (objcopy will handle all the string table, section table headers stuff etc)

Best,
Kai

On Tue, Feb 23, 2010 at 03:51:48PM +0100, Jay Vaughan wrote:
> Hi all,
> 
> I am building an application which utilizes elfutils to add NOTE records to ELF files .. 
> the purpose of this application is to provide a form of 'internal inventory control' over 
> executables being used internally in our environment, and for that purpose a NOTE record 
> is added to ELF files containing an MD5 sum of various parts of the ELF files themselves.
> 
> All has been working fine with this utility program so far, but I have run into some 
> problems with the handling of the string table - namely, where I was once realloc()'ing 
> the string table data buffer and appending my new ".note.MD5" string to the list, and this 
> isn't a very safe way of doing things - segfaults galore.  Its not stable, alas, which is 
> why I ended up implementing things this way only to discover on larger string tables that 
> there was a problem, then tracing it back (valgrind to the rescue) to the fact that libelf 
> doesn't like it when you realloc() its jiggly bits^W^Wstruct fields ..
> 
> So my next approach has been to, as I'm iterating through the original ELF file, make a 
> new string table out of the headers for each section, and upon completion (calculation of 
> the to-be-inserted md5 string, construction of a proper NOTE record, attachment of the 
> NOTE to the ELF file, etc.) I then burn the old string table and attach the new one.
> 
> However, I'm really not sure if this is the safe way to do things, or if there is any 
> other way that I could utilize - its a bit 'dodgy' to me at first blush, because what if 
> there are cases out there in our ELF collection where I somehow mess up the string table, 
> or what about the unspoken cases where a string table is expected to be something that 
> libebl doesn't reproduce - I've already noted that some string tables created through 
> libebl don't exactly 100% match the original ones (such as the ones in my redhat machines 
> libc) due to internal optimization of the string table itself (finding overlaps and not 
> inserting duplicate string values and so on..)
> 
> My question to the wise developers on this list is whether or not there is another way to 
> safely add an entry to an existing string table without doing too much 
> create-new/destroy-old processing?  I've added the use of libebl to my project, and I'm 
> under way with completing my implementation as described above, but I'd really like some 
> dialog with other ELF hackers on what they think about this method?
> 
> BTW, I plan to release my "ELFNoter" app as GPL when its working/debugged .. I wonder if 
> there is interest in including a working app to attach ELF Notes in the elfutils package? 
> I'd be happy were that the case, to provide this app for review.
> 
> -- 
> ;
> --
> Jay Vaughan
> jay...@th...
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

[Elftoolchain-developers] A safe way to re-build a string table ..

[Jay V. <jay...@th...>]

Hi all,

I am building an application which utilizes elfutils to add NOTE records to ELF files .. 
the purpose of this application is to provide a form of 'internal inventory control' over 
executables being used internally in our environment, and for that purpose a NOTE record 
is added to ELF files containing an MD5 sum of various parts of the ELF files themselves.

All has been working fine with this utility program so far, but I have run into some 
problems with the handling of the string table - namely, where I was once realloc()'ing 
the string table data buffer and appending my new ".note.MD5" string to the list, and this 
isn't a very safe way of doing things - segfaults galore.  Its not stable, alas, which is 
why I ended up implementing things this way only to discover on larger string tables that 
there was a problem, then tracing it back (valgrind to the rescue) to the fact that libelf 
doesn't like it when you realloc() its jiggly bits^W^Wstruct fields ..

So my next approach has been to, as I'm iterating through the original ELF file, make a 
new string table out of the headers for each section, and upon completion (calculation of 
the to-be-inserted md5 string, construction of a proper NOTE record, attachment of the 
NOTE to the ELF file, etc.) I then burn the old string table and attach the new one.

However, I'm really not sure if this is the safe way to do things, or if there is any 
other way that I could utilize - its a bit 'dodgy' to me at first blush, because what if 
there are cases out there in our ELF collection where I somehow mess up the string table, 
or what about the unspoken cases where a string table is expected to be something that 
libebl doesn't reproduce - I've already noted that some string tables created through 
libebl don't exactly 100% match the original ones (such as the ones in my redhat machines 
libc) due to internal optimization of the string table itself (finding overlaps and not 
inserting duplicate string values and so on..)

My question to the wise developers on this list is whether or not there is another way to 
safely add an entry to an existing string table without doing too much 
create-new/destroy-old processing?  I've added the use of libebl to my project, and I'm 
under way with completing my implementation as described above, but I'd really like some 
dialog with other ELF hackers on what they think about this method?

BTW, I plan to release my "ELFNoter" app as GPL when its working/debugged .. I wonder if 
there is interest in including a working app to attach ELF Notes in the elfutils package? 
I'd be happy were that the case, to provide this app for review.

-- 
;
--
Jay Vaughan
jay...@th...

Re: [Elftoolchain-developers] BSD libelf imported to NetBSD

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

> I just thought I'd mention NetBSD imported libelf. Please look at
> the posting and the corresponding thread:

> http://mail-index.netbsd.org/tech-toolchain/2009/12/21/msg000929.html

Yes, I've pointed the developer in question to the canonical source
tree.

Koshy

[Elftoolchain-developers] BSD libelf imported to NetBSD

[Pedro F. G. <gif...@tu...>]

Hi;

I just thought I'd mention NetBSD imported libelf. Please
look at the posting and the corresponding thread:

http://mail-index.netbsd.org/tech-toolchain/2009/12/21/msg000929.html

cheers,

Pedro.


      

[Elftoolchain-developers] [For Review] A new version of libelf-by-example tutorial

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

A new version of libelf-by-example tutorial is available at:

  http://elftoolchain.sourceforge.net/for-review/libelf-by-example-20100111.pdf

This version corresponds to SVN [664].

Notable changes from the initial (HTML/DocBook) version include:

 * An Index that maps concepts to explanations and usage examples in
   the tutorial text.

 * Experimental two-way traversal between locations in displayed
   source code and their explanations in the tutorial text.

 * The text has been updated to use the new "portable" APIs.  See
   http://sourceforge.net/apps/trac/elftoolchain/wiki/LibElfIncompatibilityRedHatElfUtils

 * Portions of the tutorial text have been revised to improve clarity
   and flow (hopefully).

I've been told that:

(a) some of the figures look klutzy (true),
(b) that the "callout markers" embedded in the sources look terrible
    (also true).

Suggestions, feedback, LaTeX typesetting tips etc. are welcome.

Thanks,
Koshy