elftoolchain-developers — Discussion on elftoolchain development.

[Elftoolchain-developers] Error adding section to existing ELF binary

[Frank T. <fra...@ts...>]

Dear all,

I am trying to add a new section with an application specific content to
an existing ELF file. Unfortunately the resulting ELF file is erroneous
as the size/offset of the new section and the section type are not
correctly set (see code snippet below).

"Readelf" indicates the following information (section 37 is the newly
added section):

...
[36] .strtab           STRTAB          00000000 013ccc 000356 00      0
  0  1
[37]                   NULL            00000000 000000 8048154 8048168
    0 65539  0

The type of the section (NULL) and the size/offset (should be 8 bytes
starting at offset 0x14022) are wrong. I have manually verified the
correct values within the data structures using a debugger. So I would
guess that something gets broken during the final call to elf_update().

OS is Kubuntu 12.04 with package 'libelf1" installed (Version indicated
is 0.152-1ubuntu).

I've read some old postings regarding the libelf support for ELF_C_RDWR
which recommended to copy the sections to a new file due to a broken
implementation. Are these bugs still present?

Or am I just missing something? Any hints?


Frank


--------------------------------------------------------------------------------------

	int fd;
	Elf *elf_ref = NULL;
	Elf32_Ehdr *ehdr;
	Elf_Scn *elf_scn, *sig_scn;
	Elf_Data *elf_data;
	Elf32_Shdr *signature_scn_header;
	unsigned char sample_data[] = {0xca, 0xfe, 0xba, 0xbe, 0xca, 0xfe,
0xba, 0xbe};

	if (argc != 2) {
		return -1;
	}

	fd = open(argv[1], O_RDWR);

	/* Protect from using a lower ELF version and initialize ELF library */
	if (elf_version(EV_CURRENT) == EV_NONE) {
		printf("ELF library init failed: %s\n", elf_errmsg(-1));
		close(fd);
		return -1;
	}

	elf_ref = elf_begin(fd, ELF_C_RDWR, NULL);

	if (elf_kind(elf_ref) != ELF_K_ELF) {
		printf("Program is not an ELF binary\n");
		close(fd);
		return -2;
	}

	sig_scn = elf_newscn(elf_ref);

	elf_data = elf_newdata(sig_scn);
	elf_data->d_align = 1;
	elf_data->d_off = 0LL ;
	elf_data->d_buf = sample_data ;
	elf_data->d_type = ELF_T_BYTE ;
	elf_data->d_size = sizeof(sample_data);
	elf_data->d_version = EV_CURRENT ;

	signature_scn_header = elf32_getshdr(sig_scn);
	signature_scn_header->sh_name = 0;
	signature_scn_header->sh_type = SHT_LOUSER + 10;

	if (elf_update(elf_ref , ELF_C_NULL ) < 0) {
		printf("ELF update failed: %s", elf_errmsg (-1));
		return -3;
	}

	(void) elf_flagshdr(sig_scn, ELF_C_SET, ELF_F_DIRTY);
	(void) elf_flagscn(sig_scn, ELF_C_SET, ELF_F_DIRTY);
	(void) elf_flagdata(elf_data, ELF_C_SET, ELF_F_DIRTY);
	(void) elf_flagehdr(elf_ref, ELF_C_SET, ELF_F_DIRTY);
	(void) elf_flagelf(elf_ref, ELF_C_SET, ELF_F_DIRTY);

	if (elf_update(elf_ref , ELF_C_WRITE ) < 0) {
		printf("ELF update failed: %s", elf_errmsg (-1));
		return -4;
	}

	elf_end(elf_ref);

	close(fd);

Re: [Elftoolchain-developers] Questions about building

[S. B. Y. <bha...@or...>]

Thanks a lot for sharing the detailed and useful info, Daniel.

I will try building using your instructions.

Regards,

Bharadwaj


On 07/21/2014 06:03 PM, Daniel Wilkerson wrote:
> In general I have found the elftoolchain documentation to be quite
> incomplete.  Below are the notes I wrote for myself on a way to build
> on Ubuntu which worked for me. I had to discover the NOGCCERROR=1
> through an amazing amount of detective work, grepping through files,
> etc.
<...>

Re: [Elftoolchain-developers] Questions about building

[Daniel W. <dan...@gm...>]

In general I have found the elftoolchain documentation to be quite
incomplete.  Below are the notes I wrote for myself on a way to build
on Ubuntu which worked for me. I had to discover the NOGCCERROR=1
through an amazing amount of detective work, grepping through files,
etc.

You will find that once you have elftoolchain building that the lack
of documentation does not stop there.  See below for some help in
getting started.

Libelf and Libdwarf are APIs to nowhere: they are full of functions
that tell you how to get a foo from a bar, but do not tell you how to
get a bar in the first place or what you can do with a foo once you
have one.  See below for some example of APIs to nowhere that I have
never figured out; if you do figure them out, please do let me know.

Daniel


=== getting started

To get started with elf, call elf_begin() and then gelf_getehdr() on that.

Iterating over elf sections: elf_nextscn().  Getting info on the
section: gelf_getshdr().  Getting the name of a section: get the elf
section string table using do_elf_getshdrstrndx(), then use
elf_strptr().

Iterating over the data in a section seems to require two levels of
iteration: elf_getdata() which gives you a sequence of Elf_Data
objects, but then for each of those is a block of data in a
elf_data->d_buf of length elf_data->d_size.

To get started with dwarf, call
Dwarf_Debug dwarf_debug;
dwarf_elf_init(elf.elf, DW_DLC_READ, NULL, NULL, &dwarf_debug, &dwarf_error);

Then, to get the root of the DWARF tree of DIE objects, make this
amazingly intuitive incantation:
dwarf_next_cu_header
      (dwarf_debug, NULL, NULL, NULL, NULL, NULL, &dwarf_error);
Yes, that is five NULL-s in a row.  Note that the dwarf_debug is an
*iterator* over the compilation units of the ELF.

THEN, do this obvious thing:
dwarf_siblingof(dwarf_debug, NULL, &root_die, &dwarf_error);
So to get the root of the DIE tree for a compilation unit, you ask for
the sibling of emptiness.  Yup.


=== an example of an API to nowhere: dwarf forms

Here are some things I have yet to figure out and are great examples
of APIs to nowhere: suppose you use dwarf_whatform() to get the form
of an attribute (pretend you know what that means), some possible
forms are as follows.

      case DW_FORM_block:
      case DW_FORM_block1:
      case DW_FORM_block2:
      case DW_FORM_block4:

Well you can use dwarf_formblock(at, &block, &dwarf_error) to get the
form block from the attribute.  This leaves you with a Dwarf_Block
*block object.  Well that's handy, but I have NO CLUE WHATSOEVER what
I can do with a Dwarf_Block object.

      case DW_FORM_exprloc:

          Dwarf_Unsigned exprloc_len;
          Dwarf_Ptr exprloc;
Same thing: dwarf_formexprloc(at, &exprloc_len, &exprloc,
&dwarf_error) leaves me with a block of memory delimited by
essentially a void* and a length.  What is in that block of stuff I
don't know.

      case DW_FORM_ref_addr:
      case DW_FORM_sec_offset:

          Dwarf_Off ref_offset;
This dwarf_global_formref(at, &ref_offset, &dwarf_error) leaves me
with some sort of global reference offset that I have no idea how to
de-reference.

      case DW_FORM_ref1:
      case DW_FORM_ref2:
      case DW_FORM_ref4:
      case DW_FORM_ref8:
      case DW_FORM_ref_udata:

I did figure out how to deref a similar sounding different kind of
reference by using dwarf_formref(at, &ref_offset, &dwarf_error) and
then using dwarf_offdie(dwarf_debug, ref_offset, &ref_die,
&dwarf_error) on the result.


=== building elftoochain on Linux

The build process will stop and tell you to do this if you do not do
it initially:

    Please download the distribution from:
            http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet\
3.8-src.tar.gz
    and unpack it into directory "../../test/tet/tet3.8".

Note that when building on Linux, the instructions are wrong: just
using pmake will not work, you must invoke it as follows:

    $ NOGCCERROR=1 pmake

You must install elftoolchain in order to build against it; it is not
enough to just use -I and -L flags as the internal headers within
elftoolchain will not find each other.  Or, if there is a way to do
it, I do not know how.

    $ sudo pmake install

On Mon, Jul 21, 2014 at 10:09 AM, S. Bharadwaj Yadavalli
<bha...@or...> wrote:
>
>
> On 07/20/2014 12:52 PM, Joseph Koshy wrote:
>>> First, apologies, if the following are newbie questions.
>>>
>>> 1. I attempted to build elftoolchain on Ubuntu and get the following
>>> kinds of warning-triggered errors for ac_detect_ar, archive_read_finish,
>>> ac_read_objs, ac_write_objs and archive_write_finish
>>>
>>> archive.c: In function ‘ac_detect_ar’:
>>> archive.c:353:2: error: ‘archive_read_support_compression_none’ is
>>> deprecated (declared at /usr/include/archive.h:323)
>>> [-Werror=deprecated-declarations]
>>>     archive_read_support_compression_none(a);
>>>     ^
>>> Is this known? What is the recommended way to address this build problem?
>>
>> 1. Which version of Ubuntu are you building on?
>
> I am building on Ubuntu 13.10.
>
>> 2. What's the version of the libarchive package that you are using?
>
> 13.1.2
>
> $ ls -l  /usr/lib/x86_64-linux-gnu/libarchive.so
> lrwxrwxrwx 1 root root 20 Apr  4  2013
> /usr/lib/x86_64-linux-gnu/libarchive.so -> libarchive.so.13.1.2
>
> Thanks,
>
> Bharadwaj
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

Re: [Elftoolchain-developers] Questions about building

[S. B. Y. <bha...@or...>]

On 07/20/2014 12:52 PM, Joseph Koshy wrote:
>> First, apologies, if the following are newbie questions.
>>
>> 1. I attempted to build elftoolchain on Ubuntu and get the following
>> kinds of warning-triggered errors for ac_detect_ar, archive_read_finish,
>> ac_read_objs, ac_write_objs and archive_write_finish
>>
>> archive.c: In function ‘ac_detect_ar’:
>> archive.c:353:2: error: ‘archive_read_support_compression_none’ is
>> deprecated (declared at /usr/include/archive.h:323)
>> [-Werror=deprecated-declarations]
>>     archive_read_support_compression_none(a);
>>     ^
>> Is this known? What is the recommended way to address this build problem?
>
> 1. Which version of Ubuntu are you building on?

I am building on Ubuntu 13.10.

> 2. What's the version of the libarchive package that you are using?

13.1.2

$ ls -l  /usr/lib/x86_64-linux-gnu/libarchive.so
lrwxrwxrwx 1 root root 20 Apr  4  2013 
/usr/lib/x86_64-linux-gnu/libarchive.so -> libarchive.so.13.1.2

Thanks,

Bharadwaj

Re: [Elftoolchain-developers] Questions about building

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

> First, apologies, if the following are newbie questions.
>
> 1. I attempted to build elftoolchain on Ubuntu and get the following
> kinds of warning-triggered errors for ac_detect_ar, archive_read_finish,
> ac_read_objs, ac_write_objs and archive_write_finish
>
> archive.c: In function ‘ac_detect_ar’:
> archive.c:353:2: error: ‘archive_read_support_compression_none’ is
> deprecated (declared at /usr/include/archive.h:323)
> [-Werror=deprecated-declarations]
>    archive_read_support_compression_none(a);
>    ^
> Is this known? What is the recommended way to address this build problem?

1. Which version of Ubuntu are you building on?
2. What's the version of the libarchive package that you are using?

Regards,
Joseph Koshy

[Elftoolchain-developers] Questions about building

[S. B. Y. <bha...@or...>]

Hi,

First, apologies, if the following are newbie questions.

1. I attempted to build elftoolchain on Ubuntu and get the following 
kinds of warning-triggered errors for ac_detect_ar, archive_read_finish, 
ac_read_objs, ac_write_objs and archive_write_finish

archive.c: In function ‘ac_detect_ar’:
archive.c:353:2: error: ‘archive_read_support_compression_none’ is 
deprecated (declared at /usr/include/archive.h:323) 
[-Werror=deprecated-declarations]
   archive_read_support_compression_none(a);
   ^
Is this known? What is the recommended way to address this build problem?

2. I stubbed out build of ar and elfcopy which are resulting in the 
above build failures to build the rest of the tools - as I am just 
interested in libelf, for now. When I run 'pmake 
DESTDIR=/full/path/to/destdir/' I only see libelf.a but not libelf.so. 
Is there a way to get the build to create the .so?

Thanks,

Bharadwaj

[Elftoolchain-developers] extract binary data from elf file

[massimiliano c. <mas...@po...>]

Hallo,

first of all sorry if this list is not the right place to post this 
question. In this case please tell me where can I find support.

I need write a program that extract binary data from an elf file.
The result should be the same using "objcopy -O binary".

I'm using libelf, and I read the doc ("libelf by example").
I am able to list segmets and sections in an elf file, and I can extract 
data from sections, but I don't know which section I neet to take into 
account. For example section like .text, and not .bss.
How can I choose the segments to extract? Or I need sections? In this 
case which sections?

best regards

Max

Re: [Elftoolchain-developers] what is the meaning of ELF64_R_SYM(rela.r_info) ?

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

> Wow.  It might help to mention this in libelf somewhere.
>
> ---- http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050697.html

Thanks.  This is being tracked in ticket #452.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] what is the meaning of ELF64_R_SYM(rela.r_info) ?

[Daniel W. <dan...@gm...>]

Wow.  It might help to mention this in libelf somewhere.

---- http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050697.html

Most architectures have the following 64 bit relocation record format:

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Xword  r_info; /* Symbol index and type of relocation */
} Elf64_Rel;

typedef struct
{
Elf64_Addr      r_offset;
Elf64_Xword    r_info;
Elf64_Sxword  r_addend;
} Elf64_Rela;

Whereas N64 has the following format:

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Word  r_sym;     /* Symbol index */
Elf64_Byte  r_ssym;    /* Special symbol */
Elf64_Byte  r_type3;   /* Relocation type */
Elf64_Byte  r_type2;   /* Relocation type */
Elf64_Byte  r_type;     /* Relocation type */
} Elf64_Rel;

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Word  r_sym;     /* Symbol index */
Elf64_Byte  r_ssym;    /* Special symbol */
Elf64_Byte  r_type3;   /* Relocation type */
Elf64_Byte  r_type2;   /* Relocation type */
Elf64_Byte  r_type;     /* Relocation type */
Elf64_Sxword  r_addend;
} Elf64_Rela;

On Thu, Jul 10, 2014 at 10:04 PM, Daniel Wilkerson
<dan...@gm...> wrote:
> If I have a Elf64_Rela and I call ELF64_R_SYM on its r_info field,
> what is the meaning of the number that I get back?  I'm getting
> numbers too large to be an index into a symbol table.
>
> Daniel
>
>       Elf64_Rela const rela = ...;
>       // from elftoolchain/common/elfdefinitions.h:
>       // typedef struct {
>       //   Elf64_Addr   r_offset;    /* location to apply relocation to */
>       //   Elf64_Xword  r_info;      /* type+section for relocation */
>       //   Elf64_Sxword r_addend;    /* constant addend */
>       // } Elf64_Rela;
>       int const sym = ELF64_R_SYM(rela.r_info);

[Elftoolchain-developers] what is the meaning of ELF64_R_SYM(rela.r_info) ?

[Daniel W. <dan...@gm...>]

If I have a Elf64_Rela and I call ELF64_R_SYM on its r_info field,
what is the meaning of the number that I get back?  I'm getting
numbers too large to be an index into a symbol table.

Daniel

      Elf64_Rela const rela = ...;
      // from elftoolchain/common/elfdefinitions.h:
      // typedef struct {
      //   Elf64_Addr   r_offset;    /* location to apply relocation to */
      //   Elf64_Xword  r_info;      /* type+section for relocation */
      //   Elf64_Sxword r_addend;    /* constant addend */
      // } Elf64_Rela;
      int const sym = ELF64_R_SYM(rela.r_info);

[Elftoolchain-developers] Get data from program header

[Franck J. <fra...@gm...>]

Hi,

Is there a simple way to get data from the program header as we can do
with sections (with elf_getdata) ?

Thanks,

Franck.

[Elftoolchain-developers] Heads-Up: Migration from Trac to SF Allura

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

Hello All,

The project's SVN repository, wiki and tickets have been migrated
to SF.Net's Allura platform and should be functional.

Please note that the location of the SVN repository has changed:

 Old: http://elftoolchain.svn.sourceforge.net/svnroot/elftoolchain
 New: https://svn.code.sf.net/p/elftoolchain/code/trunk

You can run 'svn switch' to migrate a checked-out SVN source tree:

  % cd /ROOT/OF/YOUR/SVN/CHECKOUT

  % svn switch --relocate \
       http://elftoolchain.svn.sourceforge.net/svnroot/elftoolchain \
       https://svn.code.sf.net/p/elftoolchain/code/trunk elftoolchain-code

Developers would need to use a svn+ssh:// URL:

  % svn --username YOURLOGIN switch --relocate \
       https://elftoolchain.svn.sourceforge.net/svnroot/elftoolchain \
       svn+ssh://YOU...@sv.../p/elftoolchain/code/

For 'git-svn' users, the 'git-svn-relocate' script [1] may be used
to relocate a git-svn repository.

  % git-svn-relocate OLD-URL NEW-URL

  [1]: https://gist.github.com/krlmlr/6307013


Work that remains:
- Fixing up the migrated content in the wiki.
- Turning off Trac.

Regards,
Joseph Koshy  <jk...@us...>

----- Forwarded message from Joseph Koshy <jk...@us...> -----

Date: Tue, 24 Dec 2013 13:21:45 +0530
From: Joseph Koshy <jk...@us...>
To: "elf...@li..."
	<elf...@li...>
Subject: Fwd: Heads-Up: Migration from Trac to SF Allura

Hello All,

The Elftoolchain project needs to migrate from Trac to SourceForge's
Allura platform.  Please see [1], [2] for more information about this
move.

  [1]: http://sourceforge.net/blog/hosted-apps-retirement/
  [2]: http://sourceforge.net/apps/trac/elftoolchain/ticket/395

I will be performing this migration over the next few days.

Planned steps:

1. Send out an announcement of the move to -developers (this annuncement).
2. Update the Trac wiki to inform visitors of the move.
3. Backup Trac.
4. Initiate project migration at the SF admin console.
4. Once migration finishes, migrate the wiki contents and tickets.
5. Change the project's default landing page to the project's Allura instance.
6. Manually go through our wiki pages and tickets, adding back
    important attachments and fixing any rendering errors.
7. Turn off Trac for the project.
8. Send email to -developers when the migration is complete.

Thank you for your patience while the migration is underway.

Regards,
Joseph Koshy

[Elftoolchain-developers] Fwd: Heads-Up: Migration from Trac to SF Allura

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

Hello All,

The Elftoolchain project needs to migrate from Trac to SourceForge's
Allura platform.  Please see [1], [2] for more information about this
move.

  [1]: http://sourceforge.net/blog/hosted-apps-retirement/
  [2]: http://sourceforge.net/apps/trac/elftoolchain/ticket/395

I will be performing this migration over the next few days.

Planned steps:

1. Send out an announcement of the move to -developers (this annuncement).
2. Update the Trac wiki to inform visitors of the move.
3. Backup Trac.
4. Initiate project migration at the SF admin console.
4. Once migration finishes, migrate the wiki contents and tickets.
5. Change the project's default landing page to the project's Allura instance.
6. Manually go through our wiki pages and tickets, adding back
    important attachments and fixing any rendering errors.
7. Turn off Trac for the project.
8. Send email to -developers when the migration is complete.

Thank you for your patience while the migration is underway.

Regards,
Joseph Koshy

---------- Forwarded message ----------
From: Daniel Hinojosa <dhi...@sl...>
Date: Thu, Dec 12, 2013 at 8:05 PM
Subject: Allura Migration is Ready
To: jko...@gm..., kai...@gm...
Cc: Christopher Tsai <ct...@sl...>


Hi Joseph and Kai,

Our team has completed their efforts at Trac Integration for you all
to complete your migration to the Allura platform.


Detailed instructions to complete this effort, after you first migrate
your project are below. If you would please perform that migration
ASAP and then you can run these steps to complete the Trac integration
for the Elf Tool Chain project...


To complete the migration of your project Trac tickets, these are the
next steps that need to be taken:


1) Go to https://sourceforge.net/p/elftoolchain/admin/ext/import/trac-tickets-sf/

2) Enter https://sourceforge.net/apps/trac/elftoolchain in the first box

3) Leave User Map blank.  label & mount point can be changed if desired

4) Submit and wait.  It can take quite a while and all the tickets
will show up at the end, and an email will be sent upon completion


To complete the migration of your Trac wiki, below are the next steps
to be taken:


1) Go to https://sourceforge.net/p/elftoolchain/admin/ext/import/trac-wiki/

2) Enter https://sourceforge.net/apps/trac/elftoolchain/ in first box

3) Change label and mount point if desired

4) Submit and wait, an email will be sent when done


Wiki notes/caveats:

a.) Attachments will not be imported

b.) Formatting is not handled perfectly in all cases

c.) History is not imported

d.) Cross-reference links like "r123" to commits (or those to tickets)
aren't handled on wikis


Notes: Revision and ticket references using trac-syntax will be
handled in the ticket import and the SVN commit messages (SVN itself
was imported already as part of the upgrade).


When you are 100% done and don't want to see Trac any more, go to
Admin > Tools > Admin Hosted Apps and disable Trac. This is NOT
REVERSIBLE.


If in the process of executing these steps, please connect with our
support team via email, a support ticket, or from 1300 to 2200 UTC,
via IRC on Freenode: #sourceforge


Best regards,


Daniel.



--
Daniel Hinojosa
Community Manager, SourceForge / Slashdot Media
p: 415.890.3608
e: d...@sl...
Twitter: @hinojosad
Skype: hinojosad

Re: [Elftoolchain-developers] arch specific sections

[Peng F. <van...@gm...>]

Hi Joseph Koshy,

Thanks. I find that elf_rawdata does not check the section type. I'll try
it.
Is it needed to add arch specific sections support to elf_getdata or the
arch specific sections should be handled using elf_rawdata by the caller ?
I am not sure about this.

Regards,
Peng


2013/7/1 Joseph Koshy <jk...@us...>

> Hello Peng Fan,
>
> > I am trying to use elftoolchain to handle arm elf object files.
> > But I always get error when handling ".ARM.attributes, .ARM.exidx ,
> > .ARM.extab " sections.
> >
> > I traced the source code and found that it fails at elf_data.c line 93.
> > The following is a piece of code.
> >
> > if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||
> >    elftype > ELF_T_LAST || (sh_type != SHT_NOBITS &&
> >    sh_offset + sh_size > (uint64_t) e->e_rawsize)) {
> > LIBELF_SET_ERROR(SECTION, 0);
> > return (NULL);
> > }
> > The .ARM.* sections are specific to ARM and the _libelf_xlate_shtype
> > function does not handle such
> > arch specific sections.
> >
> > I have a question about how to add support for arch specific sections,
> not
> > only to arm, but also other archs.
> >
> > I added the following code before invoke  _libelf_xlate_shtype  to handle
> > arm specific sections, but I am not
> >  sure whether this is the right way.
> >
> >   if (s->s_elf->e_u.e_elf.e_ehdr.e_ehdr32->e_machine == EM_ARM) {
> >     if ((sh_type == 0x70000003) || (sh_type == 0x70000001)) {
> >       if ((d = _libelf_allocate_data(s)) == NULL)
> >         return (NULL);
> >       d->d_buf = 0;
> >       d->d_size = 0;
> >       return (d);
> >     }
> >   }
> >    if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||
> >
> > Thanks very much.
>
> libelf doesn't know how to translate processor specific sections like the
> above.
>
> You could try the elf_rawdata() API, if you need access to the raw
> data in these sections.
>
> HTH,
> Joseph Koshy
>

Re: [Elftoolchain-developers] arch specific sections

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

Hello Peng Fan,

> I am trying to use elftoolchain to handle arm elf object files.
> But I always get error when handling ".ARM.attributes, .ARM.exidx ,
> .ARM.extab " sections.
>
> I traced the source code and found that it fails at elf_data.c line 93.
> The following is a piece of code.
>
> if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||
>    elftype > ELF_T_LAST || (sh_type != SHT_NOBITS &&
>    sh_offset + sh_size > (uint64_t) e->e_rawsize)) {
> LIBELF_SET_ERROR(SECTION, 0);
> return (NULL);
> }
> The .ARM.* sections are specific to ARM and the _libelf_xlate_shtype
> function does not handle such
> arch specific sections.
>
> I have a question about how to add support for arch specific sections, not
> only to arm, but also other archs.
>
> I added the following code before invoke  _libelf_xlate_shtype  to handle
> arm specific sections, but I am not
>  sure whether this is the right way.
>
>   if (s->s_elf->e_u.e_elf.e_ehdr.e_ehdr32->e_machine == EM_ARM) {
>     if ((sh_type == 0x70000003) || (sh_type == 0x70000001)) {
>       if ((d = _libelf_allocate_data(s)) == NULL)
>         return (NULL);
>       d->d_buf = 0;
>       d->d_size = 0;
>       return (d);
>     }
>   }
>    if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||
>
> Thanks very much.

libelf doesn't know how to translate processor specific sections like the above.

You could try the elf_rawdata() API, if you need access to the raw
data in these sections.

HTH,
Joseph Koshy

[Elftoolchain-developers] arch specific sections

[Peng F. <van...@gm...>]

Hi,
I am trying to use elftoolchain to handle arm elf object files.
But I always get error when handling ".ARM.attributes, .ARM.exidx ,
.ARM.extab " sections.

I traced the source code and found that it fails at elf_data.c line 93.
The following is a piece of code.

if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||
    elftype > ELF_T_LAST || (sh_type != SHT_NOBITS &&
    sh_offset + sh_size > (uint64_t) e->e_rawsize)) {
LIBELF_SET_ERROR(SECTION, 0);
return (NULL);
}
The .ARM.* sections are specific to ARM and the _libelf_xlate_shtype
function does not handle such
arch specific sections.

I have a question about how to add support for arch specific sections, not
only to arm, but also other archs.

I added the following code before invoke  _libelf_xlate_shtype  to handle
arm specific sections, but I am not
 sure whether this is the right way.

*  if (s->s_elf->e_u.e_elf.e_ehdr.e_ehdr32->e_machine == EM_ARM) {*
*    if ((sh_type == 0x70000003) || (sh_type == 0x70000001)) {*
*      if ((d = _libelf_allocate_data(s)) == NULL) *
*        return (NULL);*
*      d->d_buf = 0;*
*      d->d_size = 0;*
*      return (d);*
*    }*
*  }*
   if ((elftype = _libelf_xlate_shtype(sh_type)) < ELF_T_FIRST ||

Thanks very much.

Regards,
Peng

[Elftoolchain-developers] Adding type dump feature

[Nathan P. <np...@gm...>]

Hi All,

Just joined the list and this is my first list so forgive me if I'm going
about this wrong. I was wondering if it would be a valuable feature to add
something along the lines of a type dump to the readelf utility. Often
times especially on embedded systems when looking at a memory dump it's
useful after seeing a heap node that's been allocated for an object to have
a nice print out of the structure arrangement to see what all the different
member variable values are. I was thinking something along the lines of
this:

struct MyStruct
    offset: 0x00, size: 4   int     member1
    offset: 0x04, size: 4   int     member2
    offset: 0x08, size: 12 int[3] arraymember

    struct size: 20


Something along those lines for all the types in each of the compilation
units. I have a custom version of this already developed before I found out
about the elftoolchain and it is very helpful for debugging full system
crashes on embedded systems especially. I can provide more use case
information about this if necessary. Was just wanting to get a general feel
for what you guys thought of this? I can prototype it probably pretty
quickly. Would you like to see it as an optional to readelf or maybe a
seperate app? Let me know. I'd love to help on the project so even if you
guys don't like this idea maybe there's a specific beginner issue that I
could tackle. I am pretty familiar with ELF/DWARF formats since I've
written the above type utility. Thanks for your time!

-Nathan

Re: [Elftoolchain-developers] Memory leaks in libdwarf

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

Hello,

You will need to explicitly release the ELF instance allocated for descriptors
opened with dwarf_init(3). Please refer to the dwarf_finish(3) manual page for
more details and examples.

Kai

On Fri, Mar 1, 2013 at 10:23 AM, 邓尧 <to...@gm...> wrote:
> Hi,
> I just wrote a simple "hello world" program with libdwarf. It just create a
> Dwarf_Debug instance and then destroy it, simple as this, I still got memory
> leaks.
>
> elftoolchain built with command "pmake MKPIC=yes MKPROFILE=no MKLINKLIB=no
> -k", the platform is Ubuntu Linux 12.04, gcc 4.7, x86_64, kernel version
> 3.2.0.
> I tried both elftoolchain-0.6.1 and the latest svn trunk. got similar leak
> information from valgrind, here is my source code (linked against
> libelf_pic.a & libdwarf_pic.a)
>
> #include <unistd.h>
> #include <fcntl.h>
> #include <dwarf.h>
> #include <libdwarf.h>
> #include <assert.h>
>
> int main() {
>     Dwarf_Debug debug;
>     Dwarf_Error error;
>     int descriptor = open("a.out", O_RDONLY); // "a.out" is the program
> itself.
>     assert(dwarf_init(descriptor, DW_DLC_READ, NULL, NULL, &debug, &error)
> == 0);
>     dwarf_finish(debug, &error);
>     close(descriptor);
>     return 0;
> }
>
> This is the leak information reported by valgrind:
>
> ==1909== Memcheck, a memory error detector
> ==1909== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==1909== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==1909== Command: ./a.out
> ==1909==
> ==1909==
> ==1909== HEAP SUMMARY:
> ==1909==     in use at exit: 29,763 bytes in 57 blocks
> ==1909==   total heap usage: 63 allocs, 6 frees, 31,307 bytes allocated
> ==1909==
> ==1909== 29,763 (136 direct, 29,627 indirect) bytes in 1 blocks are
> definitely lost in loss record 9 of 9
> ==1909==    at 0x4C2B6CD: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==1909==    by 0x41EFFA: _libelf_allocate_elf (in /tmp/a.out)
> ==1909==    by 0x4138F6: _libelf_memory (in /tmp/a.out)
> ==1909==    by 0x411EBE: _libelf_open_object (in /tmp/a.out)
> ==1909==    by 0x410CFB: elf_begin (in /tmp/a.out)
> ==1909==    by 0x4014A7: dwarf_init (in /tmp/a.out)
> ==1909==    by 0x401187: main (dw.c:11)
> ==1909==
> ==1909== LEAK SUMMARY:
> ==1909==    definitely lost: 136 bytes in 1 blocks
> ==1909==    indirectly lost: 29,627 bytes in 56 blocks
> ==1909==      possibly lost: 0 bytes in 0 blocks
> ==1909==    still reachable: 0 bytes in 0 blocks
> ==1909==         suppressed: 0 bytes in 0 blocks
> ==1909==
> ==1909== For counts of detected and suppressed errors, rerun with: -v
> ==1909== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
>
> Thanks
> Yao
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>

[Elftoolchain-developers] Memory leaks in libdwarf

[邓尧 <to...@gm...>]

Hi,
I just wrote a simple "hello world" program with libdwarf. It just create a
Dwarf_Debug instance and then destroy it, simple as this, I still got
memory leaks.

elftoolchain built with command "pmake MKPIC=yes MKPROFILE=no MKLINKLIB=no
-k", the platform is Ubuntu Linux 12.04, gcc 4.7, x86_64, kernel version
3.2.0.
I tried both elftoolchain-0.6.1 and the latest svn trunk. got similar leak
information from valgrind, here is my source code (linked against
libelf_pic.a & libdwarf_pic.a)

#include <unistd.h>
#include <fcntl.h>
#include <dwarf.h>
#include <libdwarf.h>
#include <assert.h>

int main() {
    Dwarf_Debug debug;
    Dwarf_Error error;
    int descriptor = open("a.out", O_RDONLY); // "a.out" is the program
itself.
    assert(dwarf_init(descriptor, DW_DLC_READ, NULL, NULL, &debug, &error)
== 0);
    dwarf_finish(debug, &error);
    close(descriptor);
    return 0;
}

This is the leak information reported by valgrind:

==1909== Memcheck, a memory error detector
==1909== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==1909== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==1909== Command: ./a.out
==1909==
==1909==
==1909== HEAP SUMMARY:
==1909==     in use at exit: 29,763 bytes in 57 blocks
==1909==   total heap usage: 63 allocs, 6 frees, 31,307 bytes allocated
==1909==
==1909== 29,763 (136 direct, 29,627 indirect) bytes in 1 blocks are
definitely lost in loss record 9 of 9
==1909==    at 0x4C2B6CD: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1909==    by 0x41EFFA: _libelf_allocate_elf (in /tmp/a.out)
==1909==    by 0x4138F6: _libelf_memory (in /tmp/a.out)
==1909==    by 0x411EBE: _libelf_open_object (in /tmp/a.out)
==1909==    by 0x410CFB: elf_begin (in /tmp/a.out)
==1909==    by 0x4014A7: dwarf_init (in /tmp/a.out)
==1909==    by 0x401187: main (dw.c:11)
==1909==
==1909== LEAK SUMMARY:
==1909==    definitely lost: 136 bytes in 1 blocks
==1909==    indirectly lost: 29,627 bytes in 56 blocks
==1909==      possibly lost: 0 bytes in 0 blocks
==1909==    still reachable: 0 bytes in 0 blocks
==1909==         suppressed: 0 bytes in 0 blocks
==1909==
==1909== For counts of detected and suppressed errors, rerun with: -v
==1909== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

Thanks
Yao

[Elftoolchain-developers] trunk/isa/avr.isa

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

On Wed, Jan 16, 2013 at 10:47 AM,  <jk...@us...> wrote:
> Revision: 2899
>           http://elftoolchain.svn.sourceforge.net/elftoolchain/?rev=2899&view=rev
> Author:   jkoshy
> Date:     2013-01-16 05:17:02 +0000 (Wed, 16 Jan 2013)
> Log Message:
> -----------
> Add a preliminary description of the instruction set supported by Atmel
> AVR 8-bit CPUs.

This 8-bit CPU seemed like a good candidate for use in the initial
phases of development of the isa(1) utility:

* Its 16-bit instruction word is small enough that extensive testing
  of the code generated by isa(1) seems feasible.

* The instruction encoding itself offers scope to experiment with
  notational features that would be used for more complex
  architectures.  At the same time, the instruction encoding is more
  tractable than that of a CISC CPU like the x86.

The currently planned syntax for instruction set descriptions has been
(partially) described in a manual page: "trunk/isa/isa.5".

Comments welcome.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

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

Thank you for your review comments.

kw> I see. My only concern is that for ld(1) the symbol table can be
kw> really huge, create another copy of symbol table might be
kw> expensive.

You are right.  The proposed *_to_image() API is is flawed, because it
will lead to unnecessary memory allocation and data copying when used
with libelf.

kw> On a second thought, you're right, ld(1) can use the `iterate' API
kw> to create the Elf32_Sym/Elf64_Sym table directly, thus all of the
kw> above is not needed.

Agreed.

We would also need a `elftc_symbol_table_count()` API to help the
application size its buffers.  If we are implementing a _step() API,
the application can step through the symbol table, filling its buffer
and discarding the symbols it does not want.

(If we are supporting *_step() for unsorted tables too, then the
*_iterate() API would be redundant).

kw> The `replace' API depends on the implementation, see below. And you're
kw> right, I want 's2' to have the same symbol table index as 's1'.

Ok.

kw> I was thinking the symbol table is both a doublely linked list and
kw> a hash table. The table is iterated in insertion order, or sort
kw> order if the `sort' API has been called. The `replace' API make
kw> sure symbol `s2' has the same position in the linked list as
kw> symbol `s1', thus the same symbol index. This is useful for ld(1).

kw> If it's implemented as above, the `step' API can be used in sorted
kw> and unsorted tables?

Yes, that would be a good way to implementing it, given the desired
behaviors for the _step() and _replace() APIs.

I will update the manual page to reflect our current understanding of the
API shortly.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

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

On Sat, Dec 29, 2012 at 08:34:26AM +0100, Kai Wang wrote:
> I see. My only concern is that for ld(1) the symbol table can be
> really huge, create another copy of symbol table might be expensive.
> 
> ...
>
> How about, we keep the current elftc_symbol_table_to_image as is, and add another
> more generic transform API:
> 
> void *
> elftc_symbol_table_to_image_generic(Elftc_Symbol_Table *table, size_t *nentries,
>     int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie, void *entry),
>     size_t entsize, void *cookie, Elftc_String_Table **strtab);
> 
> Rationale:
> * API returns untyped buffer.
> * `entsize' spcifies the entry size of the returned buffer.
> * `entry' points to the entry buffer where application provided `transformfn'
>    should fill in. (The API advance the `entry' pointer internally, by adding
>    `entsize')
> 
> The idea is that elftc_symbol_table_to_image_generic can return an array of
> Elf32_Sym/Elf64_Sym instead of GElf_Sym. The returned array can be assigned to
> the `d_buf' field of an Elf_Data descriptor directly, thus avoid one more memory
> copy. (comparing to using gelf_update_sym() on returned GElf_Sym array)
> 
> Also, ld(1) can use this API to transform symbol with customized name,
> as I mentioned in my preivous mail.

Please ignore above comment.

On a second thought, you're right, ld(1) can use the `iterate' API to create the
Elf32_Sym/Elf64_Sym table directly, thus all of the above is not needed.

Thanks,
Kai

Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

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

On Thu, Dec 27, 2012 at 01:09:18PM +0530, Joseph Koshy wrote:
> > Some questions:
> > 
> > * What is the nested symbol table used for? Could you give an example?
> 
> as(1) has a macro facility (.altmacro) which supports 'local' identifiers.
> When the macro definition is used, such local names expand to unique
> IDs, different for each use of the macro.   These local names go out of
> scope when the macro ends, and can shadow symbols already seen in the
> assembler source.

I see.

> > * Is it possible to customize the elftc_symbol_table_to_image?
> > 
> >   For example, ld(1) sometimes searchs symbols by name and symbol version.
> >   To achieve that, ld(1) stores symbol name is the form "symbol@version",
> >   "atoi@FBSD_1.0" for instance. When elftc_symbol_table_to_image is called,
> >   ld(1) will want the string "atoi" in the string table, not "atoi@FBSD_1.0".
> 
> The iterate() API is intended for these kind of transformations.
> 
> For example, the application could use the iterate() API to generate
> a copy of the symbol table with the names transformed, and then use
> elftc_symbol_table_to_image() on the transformed table:

I see. My only concern is that for ld(1) the symbol table can be
really huge, create another copy of symbol table might be expensive.

> Alternatively, we could add a 'transformfn()' parameter to the
> elftc_symbol_table_to_image() API.   If non-null, the transformfn() would
> be called for each entry, prior to the entry's (ELF) in-memory image
> being created.  This function could effect an in-place transformation
> of the symbol.
> 
> The revised prototype would then look like:
> 
>     Gelf_Sym *
>     elftc_symbol_table_to_image(Elftc_Symbol_Table *table, size_t *nentries,
>          int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie), 
>          void *cookie, Elftc_String_Table **strtab);
> 
> However, this way seems less general than the first.

How about, we keep the current elftc_symbol_table_to_image as is, and add another
more generic transform API:

void *
elftc_symbol_table_to_image_generic(Elftc_Symbol_Table *table, size_t *nentries,
    int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie, void *entry),
    size_t entsize, void *cookie, Elftc_String_Table **strtab);

Rationale:
* API returns untyped buffer.
* `entsize' spcifies the entry size of the returned buffer.
* `entry' points to the entry buffer where application provided `transformfn'
   should fill in. (The API advance the `entry' pointer internally, by adding
   `entsize')

The idea is that elftc_symbol_table_to_image_generic can return an array of
Elf32_Sym/Elf64_Sym instead of GElf_Sym. The returned array can be assigned to
the `d_buf' field of an Elf_Data descriptor directly, thus avoid one more memory
copy. (comparing to using gelf_update_sym() on returned GElf_Sym array)

Also, ld(1) can use this API to transform symbol with customized name,
as I mentioned in my preivous mail.

> > * Is it possible to provide a sort API? e.g.
> > elftc_symbol_table_sort(Elftc_Symbol_Table *table,
> >   int (*cmp)(Elftc_Symbol *s1, Elftc_Symbol *s2))
> 
> Good point.   For tables with entries that have some kind of ordering
> associated with them, we could also have a 'step()' API:
> 
>     Elftc_Symbol *
>     elftc_symbol_table_step(Elftc_Symbol_Table *table,
>         Elftc_Symbol *sym, int stepdirection);
> 
> where 'stepdirection' would be one of ELFTC_STEP_NEXT | ELFTC_STEP_PREVIOUS.

See my comments below.

> There is another API that could be useful during disassembly:
> 
>     Elftc_Elf_Symbol *
>     elftc_symbol_table_lookup_value(Elftc_Symbol_Table *table,
>        uint64_t value,  off_t &offset, int searchflags);
> 
> This would return the symbol 'closest' to the specified value.
> 'searchflags' could be ELFTC_SEARCH_FORWARD | ELFTC_SEARCH_BACKWARD.

Good idea. This can be used by tools like addr2line(1) and ld(1)
as well.

> > * Is it possible to provide a "replace" API?
> >   e.g. elftc_symbol_table_replace(Elftc_Symbol_Table *table,
> > Elftc_Symbol *s1, Elftc_Symbol *s2)
> 
> >   This API can be used when, for example, symbol resolving in ld(1).
> >   When application knows symbol s1 exists in the symbol table, it wants
> >   to replace s1 with s2 and expects that s2 will have the same
> >   position in the symbol table as s1.
> 
> Could you clarify what the difference between a replace API and a
> 'delete(s1)', 'insert(s2)' sequence would be?   Do you need 's2' to be
> associated with the same (ELF) symbol table index as 's1'?

The `replace' API depends on the implementation, see below. And you're
right, I want 's2' to have the same symbol table index as 's1'.

> > * What kind of internal data structures are you going to use to
> >   implement symbol table and string table?
> 
> I was thinking of some kind of hash table for name lookups for basic
> symbol tables that have no concept of a sort order.  For "Elftc_Elf_Symbol"
> entries, we would need additional fields for dealing with ordering
> of symbols.  Suggestions welcome.

I was thinking the symbol table is both a doublely linked list and a
hash table. The table is iterated in insertion order, or sort order if
the `sort' API has been called. The `replace' API make sure symbol
`s2' has the same position in the linked list as symbol `s1', thus the
same symbol index. This is useful for ld(1).

If it's implemented as above, the `step' API can be used in sorted and
unsorted tables?

Thanks,
Kai

Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

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

> Some questions:
> 
> * What is the nested symbol table used for? Could you give an example?

as(1) has a macro facility (.altmacro) which supports 'local' identifiers.
When the macro definition is used, such local names expand to unique
IDs, different for each use of the macro.   These local names go out of
scope when the macro ends, and can shadow symbols already seen in the
assembler source.

> * Is it possible to customize the elftc_symbol_table_to_image?
> 
>   For example, ld(1) sometimes searchs symbols by name and symbol version.
>   To achieve that, ld(1) stores symbol name is the form "symbol@version",
>   "atoi@FBSD_1.0" for instance. When elftc_symbol_table_to_image is called,
>   ld(1) will want the string "atoi" in the string table, not "atoi@FBSD_1.0".

The iterate() API is intended for these kind of transformations.

For example, the application could use the iterate() API to generate
a copy of the symbol table with the names transformed, and then use
elftc_symbol_table_to_image() on the transformed table:

    int
    myfn(Elftc_Symbol *entry, void *cookie)
    {
         Elftc_Elf_Symbol *elfsym = (Elftc_Elf_Symbol *) entry;
         Elftc_Symbol_Table *newtable = (Elftc_Symbol_Table *) cookie;

         ... insert a transformed symbol into 'newtable' ;

	 return (ELFTC_ITERATE_CONTINUE);
    }

    newtable = elftc_symbol_table_create(...);
    status = elftc_symbol_iterate(oldtable, myfn, newtable);

    if (status != ELFTC_ITERATE_SUCCESS)
	error("...");
    else
	elf_section_image = elftc_symbol_table_to_image(newtable, &nentries,
            &strtab);

Alternatively, we could add a 'transformfn()' parameter to the
elftc_symbol_table_to_image() API.   If non-null, the transformfn() would
be called for each entry, prior to the entry's (ELF) in-memory image
being created.  This function could effect an in-place transformation
of the symbol.

The revised prototype would then look like:

    Gelf_Sym *
    elftc_symbol_table_to_image(Elftc_Symbol_Table *table, size_t *nentries,
         int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie), 
         void *cookie, Elftc_String_Table **strtab);

However, this way seems less general than the first.

> * How does elftc_symbol_table_to_image know where to find symbol size, value,
>   shndx information?
> 
>   Suppose I define a struct:
> 
>   struct _MySymbol {
>         Elftc_Symbol    sym_base;
>         uint64_t            sym_size;
>         uint64_t            sym_value;
>         uint64_t            sym_shndx;
>   }
> 
>   How does elftc_symbol_table_to_image know it should use sym_size,
>   sym_value etc? Or it just return an array of GElf_Sym and let
>   the application to fill in the value?

The _to_image() function only works with subtypes of
"Elftc_Elf_Symbol". This type is:

     typedef struct _Elftc_Elf_Symbol {
        Elftc_Symbol	sym_base;
	Gelf_Sym	sym_elf;
	.. other fields and flags, e.g., controlling sort order that
	   haven't been finalized yet. ..
     } Elftc_Elf_Symbol;

I hadn't provided the definition of "Elftc_Elf_Symbol" in the manual page,
apologies.

> * Is it possible to provide a sort API? e.g.
> elftc_symbol_table_sort(Elftc_Symbol_Table *table,
>   int (*cmp)(Elftc_Symbol *s1, Elftc_Symbol *s2))

Good point.   For tables with entries that have some kind of ordering
associated with them, we could also have a 'step()' API:

    Elftc_Symbol *
    elftc_symbol_table_step(Elftc_Symbol_Table *table,
        Elftc_Symbol *sym, int stepdirection);

where 'stepdirection' would be one of ELFTC_STEP_NEXT | ELFTC_STEP_PREVIOUS.

There is another API that could be useful during disassembly:

    Elftc_Elf_Symbol *
    elftc_symbol_table_lookup_value(Elftc_Symbol_Table *table,
       uint64_t value,  off_t &offset, int searchflags);

This would return the symbol 'closest' to the specified value.
'searchflags' could be ELFTC_SEARCH_FORWARD | ELFTC_SEARCH_BACKWARD.

> * Is it possible to provide a "replace" API?
>   e.g. elftc_symbol_table_replace(Elftc_Symbol_Table *table,
> Elftc_Symbol *s1, Elftc_Symbol *s2)

>   This API can be used when, for example, symbol resolving in ld(1).
>   When application knows symbol s1 exists in the symbol table, it wants
>   to replace s1 with s2 and expects that s2 will have the same
>   position in the symbol table as s1.

Could you clarify what the difference between a replace API and a
'delete(s1)', 'insert(s2)' sequence would be?   Do you need 's2' to be
associated with the same (ELF) symbol table index as 's1'?

> * What kind of internal data structures are you going to use to
>   implement symbol table and string table?

I was thinking of some kind of hash table for name lookups for basic
symbol tables that have no concept of a sort order.  For "Elftc_Elf_Symbol"
entries, we would need additional fields for dealing with ordering
of symbols.  Suggestions welcome.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

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

On Wed, Dec 26, 2012 at 6:42 AM, Joseph Koshy
<jk...@us...> wrote:
> Hello All,
>
> The proposed `elftc_symbol_table*()` and `elftc_string_table*()`
> functions are convenience APIs for managing ELF symbol tables [1] and
> string tables [2], respectively.
>
> These functions would be useful in implementing as(1), and could also
> help reduce code duplication in our source tree.
>
> I have added reference documentation for these proposed functions to
> the source tree in changesets [2819] and [2821].
>
> Your review & comments of these APIs would be appreciated.

Hi,

I just briefly read the manual pages. The APIs look really good in general.
Besides as(1), I think it can be used in elfcopy(1), ld(1) and other tools.

Some questions:

* What is the nested symbol table used for? Could you give an example?

* Is it possible to customize the elftc_symbol_table_to_image?

  For example, ld(1) sometimes searchs symbols by name and symbol version.
  To achieve that, ld(1) stores symbol name is the form "symbol@version",
  "atoi@FBSD_1.0" for instance. When elftc_symbol_table_to_image is called,
  ld(1) will want the string "atoi" in the string table, not "atoi@FBSD_1.0".

* How does elftc_symbol_table_to_image know where to find symbol size, value,
  shndx information?

  Suppose I define a struct:

  struct _MySymbol {
        Elftc_Symbol    sym_base;
        uint64_t            sym_size;
        uint64_t            sym_value;
        uint64_t            sym_shndx;
  }

  How does elftc_symbol_table_to_image know it should use sym_size,
sym_value etc?
  Or it just return an array of GElf_Sym and let the application to
fill in the value?

* Is it possible to provide a sort API? e.g.
elftc_symbol_table_sort(Elftc_Symbol_Table *table,
  int (*cmp)(Elftc_Symbol *s1, Elftc_Symbol *s2))

* Is it possible to provide a "replace" API?
  e.g. elftc_symbol_table_replace(Elftc_Symbol_Table *table,
Elftc_Symbol *s1, Elftc_Symbol *s2)

  This API can be used when, for example, symbol resolving in ld(1).
When application
  knows symbol s1 exists in the symbol table, it wants to replace s1
with s2 and expects
  that s2 will have the same position in the symbol table as s1.

* What kind of internal data structures are you going to use to
implement symbol table
  and string table?

Will probably have more questions later when I read the string table
API manual page.
Thanks again for working on these symbol table APIs! We really need
these since long
ago.

Thanks,
Kai