elftoolchain-developers — Discussion on elftoolchain development.

[Elftoolchain-developers] [Linux][bmake] zlib is not available error

[Matúš O. <ole...@gm...>]

Hi,
I'm trying to compile elf-toolchain on Alpine Linux using bmake and clang,
and I get this error : "ld: error: zlib is not available". Which is weird
in many ways, first of all it should be complaining about -lz, on the other
hand I have installed zlib-dev. Also I'm using lld as linker.

Full log:
===> common
/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/common/native-elf-format
> native-elf-format.h || rm native-elf-format.h
===> libelf
cc -pipe -g    -MD -MF elf.d -MT elf.o -I.
-I/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf
-I/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf/../com
mon -D_FORTIFY_SOURCE=2    -c -pg -DGPROF -DPROF elf.c -o elf.po.o
ld: error: zlib is not available
*** [elf.po] Error code 1

bmake[1]: stopped in
/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf
1 error

bmake[1]: stopped in
/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf
*** [all] Error code 1

bmake: stopped in
/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain
1 error

bmake: stopped in
/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain

Thanks for your support.

[Elftoolchain-developers] "Augmentation: zRS" on signal frames

[David Y. <dyo...@po...>]

I've found that in elftoolchain 0.7.1, the libdwarf function
dwarf_get_fde_list_eh() exits with an error when an object has a CIE
with 'S'-augmentation in its .eh_frame section:

Augmentation: zRS

The augmentation has something to do with signal frames.

I've worked around this by slightly patching libdwarf_frame.c:

--- a/external/bsd/elftoolchain/libdwarf/libdwarf_frame.c
+++ b/external/bsd/elftoolchain/libdwarf/libdwarf_frame.c
@@ -143,6 +143,7 @@ _dwarf_frame_parse_lsb_cie_augment(Dwarf_Debug dbg, Dwarf_Cie cie,
        while (*aug_p != '\0') {
                switch (*aug_p) {
                case 'L':
+               case 'S':
                        /* Skip one augment in augment data. */
                        augdata_p++;
                        break;
 

Without the patch, an 'S'-augmentation makes
_dwarf_frame_parse_lsb_cie_augment() exit with an error at the switch's
default case.

Dave

-- 
David Young
dy...@po...    Urbana, IL    (217) 721-9981

[Elftoolchain-developers] how to change note in a core file

[Chuck T. <ct...@gm...>]

Hi

I'm trying to use libelf to modify the file created from a core dump
but am struggling with the right approach to use. Parts of the
application work fine (e.g. modifying the ELF header), but modifying
the Notes section is problematic. One attempt was to use the pointer
returned from elf_rawfile() directly, but writing to this segfaults (I
think) because libelf mmap's the file read-only. Are there any other
approaches people would recommend? TIA.

--chuck

Re: [Elftoolchain-developers] small memory leak in libdwarf.

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

2017-08-31 4:47 GMT+01:00 John Kearney <det...@gm...>:
> Not sure if this is the correct plae to post this?
>
> This is just a small memory leak.fix.
>
> svn diff libdwarf/libdwarf_elf_init.c
> Index: libdwarf/libdwarf_elf_init.c
> ===================================================================
> --- libdwarf/libdwarf_elf_init.c        (revision 3564)
> +++ libdwarf/libdwarf_elf_init.c        (working copy)
> @@ -383,6 +383,7 @@
>         if (e->eo_shdr)
>                 free(e->eo_shdr);
>
> +       elf_end(e->eo_elf);
>         free(e);
>         free(iface);

Thanks for your email.

Unfortunately the e->eo_elf need not be owned by libdwarf; it could have been
used as a parameter to the dwarf_elf_init() API.  We would need to track
ownership using an internal flag of some kind.

I have filed ticket #553 to track this bug.

Regards,
Joseph Koshy

[Elftoolchain-developers] small memory leak in libdwarf.

[John K. <det...@gm...>]

Not sure if this is the correct plae to post this?

This is just a small memory leak.fix.

svn diff libdwarf/libdwarf_elf_init.c
Index: libdwarf/libdwarf_elf_init.c
===================================================================
--- libdwarf/libdwarf_elf_init.c        (revision 3564)
+++ libdwarf/libdwarf_elf_init.c        (working copy)
@@ -383,6 +383,7 @@
        if (e->eo_shdr)
                free(e->eo_shdr);

+       elf_end(e->eo_elf);
        free(e);
        free(iface);

Cheers.

Re: [Elftoolchain-developers] portable format strings?

[David Y. <dyo...@po...>]

On Mon, Jun 12, 2017 at 05:32:49PM -0400, Ed Maste wrote:
> On 8 June 2017 at 18:25, David Young <dyo...@po...> wrote:
> > Are there elftoolchain-blessed format strings Dwarf_Off, Dwarf_Addr,
> > etc?
> 
> Not at the moment. Would you be able to enumerate the set of them
> available in the other leading brand of libdwarf?

Sure I can.

On a second look, the set is not comprehensive.  I would hope for a
format string for Dwarf_Half, Dwarf_Addr, and Dwarf_Small.  Here is what
the other leading brand (OLB) provides:

DW_PR_DUu: the target's decimal format string for Dwarf_Unsigned decimal
DW_PR_DUx: hexadecimal Dwarf_Unsigned

DW_PR_DSd: decimal Dwarf_Signed
DW_PR_DSx: hexadecimal Dwarf_Signed

DW_PR_XZEROS is also defined: the intention seems to be that you would
printf("%" DW_PR_XZEROS DW_PR_DUx "\n", x), for x a Dwarf_Unsigned, to
print it with 0 padding on the left.

Sorry for the delayed response.

Dave

-- 
David Young
dy...@po...    Urbana, IL    (217) 721-9981

Re: [Elftoolchain-developers] portable format strings?

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

On 8 June 2017 at 18:25, David Young <dyo...@po...> wrote:
> Are there elftoolchain-blessed format strings Dwarf_Off, Dwarf_Addr,
> etc?

Not at the moment. Would you be able to enumerate the set of them
available in the other leading brand of libdwarf?

[Elftoolchain-developers] portable format strings?

[David Y. <dyo...@po...>]

Are there elftoolchain-blessed format strings Dwarf_Off, Dwarf_Addr,
etc?

The other leading brand of libdwarf provides macros such as DW_PR_DUx,
which works for Dwarf_Unsigned like PRIx64 does for uint64_t.

Dave

-- 
David Young
dy...@po...    Urbana, IL    (217) 721-9981

[Elftoolchain-developers] elftoolchain ld patches

[BwackNinja <bwa...@gm...>]

Hi,

I've been watching the project, and trying out elftoolchain's linker,
though I'm running it on Linux. It looks like it mostly works.

I've gotten it to link a working musl libc. That involved changing it
to link as a dynamic executable despite not linking to any shared
libraries, as well as some small fixes. The one thing I'm unsure about
here is the change I made to ld_reloc.c. It makes a working musl libc,
but I got to that point by looking at the symbols musl was segfaulting
on when loading itself and the output differences in readelf between
musl linked with binutils and elftoolchain.

I've also gotten it to link a working
llvm/clang/lld/libc++/libc++abi/libunwind as well. That was mostly
dealing with some peculiarities of musl (empty libm.a, etc), falling
back to parsing a file as a linker script when the it isn't detected
as a library (for linking with libc++, because libc++.so is a linker
script), and dealing with archive files being referenced multiple
times on the command line, resulting in duplicate symbols. I also had
to disable llvm's version scripts passed to the linker when compiling
it, which were causing ld to segfault. I haven't looked into that much
yet.

Patches attached.

~ BwackNinja

[Elftoolchain-developers] Unconditional relocation of .debug_str by libelf/libdwarf

[Kaletta, P. <pau...@in...>]

Hi,

we have an in-house-tool that is similar to the dwarfdump program that
comes with David Anderson's libdwarf, except that its output format is
tailored towards our specific needs.  Currently our tool uses David
Anderson's libdwarf, and the libelf from
http://www.mr511.de/software/english.html, but I wanted to get it to
work with the libraries from the BSD ELF Tool Chain.

The program works just like dwarfdump.  In very rough terms, the
following function is applied to each die:

pretty_print(die):
    print name of die

    for each attribute of die:
        print name and value of attribute

    for each sibling of die:
        pretty_print(sibling)

This works nicely for most attributes, except that with the BSD ELF
Tool Chain libelf and libdwarf

    dwarf_formstring(attribute_list[i], &name, &error)

ALWAYS returns the attribute name that is the very first entry in the
.debug_str section.

The result is that ONE bogus attribute name is printed for ALL
occurrences of DW_AT_producer, DW_AT_name, and DW_AT_comp_dir.

I did some debugging and compared the bytes as they are interpreted by
the libdwarf functions with the bytes as they are stored in the input
file.  I found that the indices into .debug_str are all correct in the
object file, but at the point where they are parsed by the libdwarf
routines, all indices are zeros.

I found that the BSD ELF Tool Chain libelf/libdwarf apply relocations
to .debug_str, whereas the other libelf/libdwarf combination does not
do this.

Indeed this strange behavior can be disabled by calling
dwarf_set_reloc_application(false) prior to dwarf_init(...).  This
works around the issue.

I strongly suspect that this is a bug.

Best regards,
Paul

ps:

Overall I'm very happy with your code, I found a few issues and sent a
patch to Kai Wang in a private mail.

Porting our program was quite easy.  I had to change a few macros that
are used in format strings.  In David Anderson's libdwarf,
dwarf_formref and dwarf_global_formref sometimes indicate an invalid
attribute form with DW_DLE_BAD_REF_FORM, while your libdwarf always
uses DW_DLE_ATTR_FORM_BAD.

Keep up the good work!
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

[Sam H. <sam...@gm...>]

Ed,

Apologies for the delay.

I made and installed libelf with the debug flags. It put itself in
/usr/lib (I wasn't quite expecting that).

Whenever I invoke many binaries on FreeBSD, I get this error message:

/usr/lib/libelf.so.1: version FBSD_1.0 required by
/usr/lib/libexecinfo.so.1 not found

What did I do wrong?

--Sam

On Mon, May 16, 2016 at 1:13 PM, Sam Habiel <sam...@gm...> wrote:
> Thank you Ed! You're a swell guy, as they say in the 50's.
>
> I will reply to you next week, when I get a chance to actually perform
> these steps.
>
> --Sam
>
> On Mon, May 16, 2016 at 12:25 PM, Ed Maste <em...@fr...> wrote:
>> On 15 May 2016 at 22:05, Sam Habiel <sam...@gm...> wrote:
>>>
>>> Having said that though, I don't have enough experience in FreeBSD to
>>> be able to answer all your questions; and I never had to use gdb to
>>> debug a linked library before. Let me answer and ask in turns:
>>
>> Sorry about that - I wasn't sure how much or little detail to provide.
>> I'm happy to work through the details with you.
>>
>>> 1. I downloaded FreeBSD 10.3 and libelf came with the system without
>>> me installing anything. I presume then it's in the FreeBSD source tree
>>> since I didn't install that one from the ports tree, correct?
>>
>> That's correct.
>>
>> jkoshy@ and others developed the BSD-licensed libelf in FreeBSD
>> starting in the mid-2000s, and it's still that version that's in
>> FreeBSD 10.
>>
>> libelf and other tools moved from FreeBSD to the ELF Tool Chain
>> project  out to ELF Tool Chain later on, and were reimported into
>> FreeBSD for FreeBSD 11.
>>
>>> 2. Where is the upstream version? And how can I compile it to replace
>>> the ones that my makefile grabs? (I think I can figure this one out,
>>> but a hint will help).
>>
>> You can get it here:
>> svn checkout svn://svn.code.sf.net/p/elftoolchain/code/trunk elftoolchain-code
>> A top level 'make' will build libelf, libdwarf, and ELF Tool Chain
>> versions of strip, nm, size, etc.
>>
>> Adding -L (and -I) options to CFLAGS when building your software
>> should be sufficient to pick it up. You mentioned that it works with a
>> libelf from ports, and the same scheme used to build against that one
>> should work for your own elftoolchain build.
>>
>>> 3. How do use gdb to step into such a library? Would just typing "s"
>>> take you into the code if everything else is in place?
>>
>> Yes. You can build the library with -g, and -O0 to make debugging work
>> better. E.g., with flags for 2. and 3.:
>> CFLAGS="-g -O0 -L/example/src/elftoolchain/libelf
>> -I/example/src/elftoolchain/libelf" make
>>
>> You can set a breakpoint on elf_update, and then step through to find
>> out where the error is returned.
>
>
>
> --
> Sam Habiel, Pharm.D.
> VISTA Expertise Network



-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

Re: [Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

[Sam H. <sam...@gm...>]

Thank you Ed! You're a swell guy, as they say in the 50's.

I will reply to you next week, when I get a chance to actually perform
these steps.

--Sam

On Mon, May 16, 2016 at 12:25 PM, Ed Maste <em...@fr...> wrote:
> On 15 May 2016 at 22:05, Sam Habiel <sam...@gm...> wrote:
>>
>> Having said that though, I don't have enough experience in FreeBSD to
>> be able to answer all your questions; and I never had to use gdb to
>> debug a linked library before. Let me answer and ask in turns:
>
> Sorry about that - I wasn't sure how much or little detail to provide.
> I'm happy to work through the details with you.
>
>> 1. I downloaded FreeBSD 10.3 and libelf came with the system without
>> me installing anything. I presume then it's in the FreeBSD source tree
>> since I didn't install that one from the ports tree, correct?
>
> That's correct.
>
> jkoshy@ and others developed the BSD-licensed libelf in FreeBSD
> starting in the mid-2000s, and it's still that version that's in
> FreeBSD 10.
>
> libelf and other tools moved from FreeBSD to the ELF Tool Chain
> project  out to ELF Tool Chain later on, and were reimported into
> FreeBSD for FreeBSD 11.
>
>> 2. Where is the upstream version? And how can I compile it to replace
>> the ones that my makefile grabs? (I think I can figure this one out,
>> but a hint will help).
>
> You can get it here:
> svn checkout svn://svn.code.sf.net/p/elftoolchain/code/trunk elftoolchain-code
> A top level 'make' will build libelf, libdwarf, and ELF Tool Chain
> versions of strip, nm, size, etc.
>
> Adding -L (and -I) options to CFLAGS when building your software
> should be sufficient to pick it up. You mentioned that it works with a
> libelf from ports, and the same scheme used to build against that one
> should work for your own elftoolchain build.
>
>> 3. How do use gdb to step into such a library? Would just typing "s"
>> take you into the code if everything else is in place?
>
> Yes. You can build the library with -g, and -O0 to make debugging work
> better. E.g., with flags for 2. and 3.:
> CFLAGS="-g -O0 -L/example/src/elftoolchain/libelf
> -I/example/src/elftoolchain/libelf" make
>
> You can set a breakpoint on elf_update, and then step through to find
> out where the error is returned.



-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

Re: [Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

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

On 15 May 2016 at 22:05, Sam Habiel <sam...@gm...> wrote:
>
> Having said that though, I don't have enough experience in FreeBSD to
> be able to answer all your questions; and I never had to use gdb to
> debug a linked library before. Let me answer and ask in turns:

Sorry about that - I wasn't sure how much or little detail to provide.
I'm happy to work through the details with you.

> 1. I downloaded FreeBSD 10.3 and libelf came with the system without
> me installing anything. I presume then it's in the FreeBSD source tree
> since I didn't install that one from the ports tree, correct?

That's correct.

jkoshy@ and others developed the BSD-licensed libelf in FreeBSD
starting in the mid-2000s, and it's still that version that's in
FreeBSD 10.

libelf and other tools moved from FreeBSD to the ELF Tool Chain
project  out to ELF Tool Chain later on, and were reimported into
FreeBSD for FreeBSD 11.

> 2. Where is the upstream version? And how can I compile it to replace
> the ones that my makefile grabs? (I think I can figure this one out,
> but a hint will help).

You can get it here:
svn checkout svn://svn.code.sf.net/p/elftoolchain/code/trunk elftoolchain-code
A top level 'make' will build libelf, libdwarf, and ELF Tool Chain
versions of strip, nm, size, etc.

Adding -L (and -I) options to CFLAGS when building your software
should be sufficient to pick it up. You mentioned that it works with a
libelf from ports, and the same scheme used to build against that one
should work for your own elftoolchain build.

> 3. How do use gdb to step into such a library? Would just typing "s"
> take you into the code if everything else is in place?

Yes. You can build the library with -g, and -O0 to make debugging work
better. E.g., with flags for 2. and 3.:
CFLAGS="-g -O0 -L/example/src/elftoolchain/libelf
-I/example/src/elftoolchain/libelf" make

You can set a breakpoint on elf_update, and then step through to find
out where the error is returned.

Re: [Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

[Sam H. <sam...@gm...>]

Ed, thank you for your reply.

It will take me a while to get back to you... as this is a hobby thing
and I will get back to it when I get a chance.

Having said that though, I don't have enough experience in FreeBSD to
be able to answer all your questions; and I never had to use gdb to
debug a linked library before. Let me answer and ask in turns:

1. I downloaded FreeBSD 10.3 and libelf came with the system without
me installing anything. I presume then it's in the FreeBSD source tree
since I didn't install that one from the ports tree, correct?
2. Where is the upstream version? And how can I compile it to replace
the ones that my makefile grabs? (I think I can figure this one out,
but a hint will help).
3. How do use gdb to step into such a library? Would just typing "s"
take you into the code if everything else is in place?

--Sam

On Sun, May 15, 2016 at 4:47 PM, Ed Maste <em...@fr...> wrote:
> On 15 May 2016 at 16:43, Sam Habiel <sam...@gm...> wrote:
>> First time on list,
>>
>> Failure here: https://github.com/shabiel/fis-gtm/blob/freebsd/sr_x86_64/obj_filesp.c#L322
>>
>> I added a line after it:
>>                 FPRINTF(stderr, elf_errmsg(elf_errno()));
>>
>> And this line says: Invalid data buffer descriptor.
>>
>> Ports tree libelf doesn't have this problem.
>>
>> root@:~/repos/fis-gtm # uname -a
>> FreeBSD  10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25
>> 02:10:02 UTC 2016
>> ro...@re...:/usr/obj/usr/src/sys/GENERIC  amd64
>
> To confirm, this is the libelf in the FreeBSD source tree, not the
> upstream elftoolchain version? If so, can you test the upstream
> version? I don't anticipate any differences, but it will be a better
> base for experimentation and debugging.
>
> I see three
> LIBELF_SET_ERROR(DATA, 0);
> in libelf/elf_update.c. If you can run the application under a
> debugger I would set a breakpoint on them and see which case returned
> the error, which should give a suggestion on next steps.
>
> -Ed



-- 
Sam Habiel, Pharm.D.
VISTA Expertise Network

Re: [Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

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

On 15 May 2016 at 16:43, Sam Habiel <sam...@gm...> wrote:
> First time on list,
>
> Failure here: https://github.com/shabiel/fis-gtm/blob/freebsd/sr_x86_64/obj_filesp.c#L322
>
> I added a line after it:
>                 FPRINTF(stderr, elf_errmsg(elf_errno()));
>
> And this line says: Invalid data buffer descriptor.
>
> Ports tree libelf doesn't have this problem.
>
> root@:~/repos/fis-gtm # uname -a
> FreeBSD  10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25
> 02:10:02 UTC 2016
> ro...@re...:/usr/obj/usr/src/sys/GENERIC  amd64

To confirm, this is the libelf in the FreeBSD source tree, not the
upstream elftoolchain version? If so, can you test the upstream
version? I don't anticipate any differences, but it will be a better
base for experimentation and debugging.

I see three
LIBELF_SET_ERROR(DATA, 0);
in libelf/elf_update.c. If you can run the application under a
debugger I would set a breakpoint on them and see which case returned
the error, which should give a suggestion on next steps.

-Ed

Re: [Elftoolchain-developers] [elftoolchain-vcs-changes] SF.net SVN: elftoolchain:[3470] trunk

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

On 15 May 2016 at 23:16,  <em...@us...> wrote:
> Revision: 3470
>           http://sourceforge.net/p/elftoolchain/code/3470
> Author:   emaste
> Date:     2016-05-15 23:16:45 +0000 (Sun, 15 May 2016)
> Log Message:
> -----------
> elfdump: handle PT_GNU_{EH_FRAME,STACK,RELRO} phdr types

Prior to r3464 these segments were incorrectly reported as having a
type of e.g PT_NULL or PT_LOAD. As of r3464 they were displayed as
Unknown: 0x<hex>, and a number of elfdump tests started failing
because the captured output included that bug.

The tests are now updated to capture the new output.

[Elftoolchain-developers] elf_update() returns error "Invalid data buffer descriptor" on FreeBSD 10.3

[Sam H. <sam...@gm...>]

First time on list,

Failure here: https://github.com/shabiel/fis-gtm/blob/freebsd/sr_x86_64/obj_filesp.c#L322

I added a line after it:
                FPRINTF(stderr, elf_errmsg(elf_errno()));

And this line says: Invalid data buffer descriptor.

Ports tree libelf doesn't have this problem.

root@:~/repos/fis-gtm # uname -a
FreeBSD  10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25
02:10:02 UTC 2016
ro...@re...:/usr/obj/usr/src/sys/GENERIC  amd64

I don't have any idea on how to find out what version number is the
libelf library on FreeBSD.

Any ideas on how I would troubleshoot this?

-- 
Sam

Re: [Elftoolchain-developers] elfdump -Sd formatting (Solaris)

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

Richard PALO wrote:
> rp> Checking out 0.7.1, I notice in general that the tags output under
> rp> the Solaris elfdump  format maintain the 'DT_' prefix, as follows:

I hope we can move more common functionality to libelftc from
readelf/elfdump -- I did it for relocation type strings recently.
While looking at others I see that one common difference is whether or
not prefixes are printed (SHT_, DT_, etc.); perhaps we can have these
type->string mapping functions accept an enum to choose one of several
styles.

On 13 March 2016 at 11:40, Joseph Koshy <jk...@us...> wrote:
> Related question: would you recommend a freely available Solaris clone
> that we could use to look at Solaris compatibility issues?

I've been using SmartOS for this, available from:
http://wiki.smartos.org/display/DOC/Download+SmartOS

I've tried it out in QEMU; it takes much longer than FreeBSD to start
up, but seems to work just fine.

On a related note I have some work in progress for ELF notes
formatting in elfdump that I plan to post for review shortly.

Re: [Elftoolchain-developers] elfdump -Sd formatting (Solaris)

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

rp> Checking out 0.7.1, I notice in general that the tags output under
rp> the Solaris elfdump  format maintain the 'DT_' prefix, as follows:

Related question: would you recommend a freely available Solaris clone
that we could use to look at Solaris compatibility issues?

Regards,
Joseph Koshy

[Elftoolchain-developers] elfdump -Sd formatting (Solaris)

[Richard P. <ri...@ne...>]

Checking out 0.7.1, I notice in general that the tags output under
the Solaris elfdump  format maintain the 'DT_' prefix, as follows:

elftoolchain:
> Dynamic Section:  .dynamic
>      index  tag               value
>        [0]  DT_NEEDED        0x7e66           libcrypto.so.1.0.0
>        [1]  DT_NEEDED        0x7e79           liblzma.so.5
>        [2]  DT_NEEDED        0x7e86           libmd.so.1
>        [3]  DT_NEEDED        0x7dbb           libpthread.so.1
>        [4]  DT_NEEDED        0x7e91           librt.so.1
>        [5]  DT_NEEDED        0x7e9c           libbz2.so.0
>        [6]  DT_NEEDED        0x7ea8           libz.so.1
>        [7]  DT_NEEDED        0x7de6           libc.so.1
>        [8]  DT_INIT          0x80010
>        [9]  DT_FINI          0x80040
>       [10]  DT_SONAME        0x7eb2           libarchive.so.13
>       [11]  DT_RUNPATH       0x7ec3           /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib
>       [12]  DT_RPATH         0x7ec3           /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib
>       [13]  DT_HASH          0xc9c
>       [14]  DT_STRTAB        0x7e3c
>       [15]  DT_STRSZ         0x8119
>       [16]  DT_SYMTAB        0x55cc
>       [17]  DT_SYMENT        0x10
>       [18]  <unknown: 0x60000011> 
>       [19]  <unknown: 0x60000012> 
>       [20]  <unknown: 0x60000013> 
>       [21]  <unknown: 0x60000014> 
>       [22]  <unknown: 0x60000015> 
>       [23]  DT_SUNW_CHECKSUM 
>       [24]  DT_VERNEED       0xff58
>       [25]  DT_VERNEEDNUM    0x2
>       [26]  DT_RELCOUNT      
>       [27]  DT_PLTRELSZ      0xe60
>       [28]  DT_PLTREL        0x11
>       [29]  DT_JMPREL        0x12348
>       [30]  DT_REL           0x11878
>       [31]  DT_RELSZ         0x1930
>       [32]  DT_RELENT        0x8
>       [33]  DT_SYMINFO (DT_ADDRRNGHI) 
>       [34]  DT_SYMINSZ       
>       [35]  DT_SYMINENT (DT_VALRNGHI) 
>       [36]  DT_FLAGS         
>       [37]  DT_FLAGS_1       
>       [38]  <unknown: 0x60000019> 
>       [39]  <unknown: 0x6000001b> 
>       [40]  DT_PLTGOT        0xa0fc8
>       [41]  DT_NULL          
>       [42]  DT_NULL          
>       [43]  DT_NULL          
>       [44]  DT_NULL          
>       [45]  DT_NULL          
>       [46]  DT_NULL          
>       [47]  DT_NULL          
>       [48]  DT_NULL          
>       [49]  DT_NULL          
>       [50]  DT_NULL          
>       [51]  DT_NULL          

SunOS:
> Dynamic Section:  .dynamic
>      index  tag                value
>        [0]  NEEDED            0x7e66              libcrypto.so.1.0.0
>        [1]  NEEDED            0x7e79              liblzma.so.5
>        [2]  NEEDED            0x7e86              libmd.so.1
>        [3]  NEEDED            0x7dbb              libpthread.so.1
>        [4]  NEEDED            0x7e91              librt.so.1
>        [5]  NEEDED            0x7e9c              libbz2.so.0
>        [6]  NEEDED            0x7ea8              libz.so.1
>        [7]  NEEDED            0x7de6              libc.so.1
>        [8]  INIT              0x80010             
>        [9]  FINI              0x80040             
>       [10]  SONAME            0x7eb2              libarchive.so.13
>       [11]  RUNPATH           0x7ec3              /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib
>       [12]  RPATH             0x7ec3              /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib
>       [13]  HASH              0xc9c               
>       [14]  STRTAB            0x7e3c              
>       [15]  STRSZ             0x8119              
>       [16]  SYMTAB            0x55cc              
>       [17]  SYMENT            0x10                
>       [18]  SUNW_SYMTAB       0x20dc              
>       [19]  SUNW_SYMSZ        0x5d60              
>       [20]  SUNW_SORTENT      0x4                 
>       [21]  SUNW_SYMSORT      0x10578             
>       [22]  SUNW_SYMSORTSZ    0x1300              
>       [23]  CHECKSUM          0x21cf              
>       [24]  VERNEED           0xff58              
>       [25]  VERNEEDNUM        0x2                 
>       [26]  RELCOUNT          0x111               
>       [27]  PLTRELSZ          0xe60               
>       [28]  PLTREL            0x11                
>       [29]  JMPREL            0x12348             
>       [30]  REL               0x11878             
>       [31]  RELSZ             0x1930              
>       [32]  RELENT            0x8                 
>       [33]  SYMINFO           0x280               
>       [34]  SYMINSZ           0xa1c               
>       [35]  SYMINENT          0x4                 
>       [36]  FLAGS             0                   0
>       [37]  FLAGS_1           0                   0
>       [38]  SUNW_STRPAD       0x200               
>       [39]  SUNW_LDMACH       0x3e                EM_AMD64
>       [40]  PLTGOT            0xa0fc8             
>    [41-51]  NULL              0                   

Is there any particular reason this needs to be different, or would 
a patch to align more closely with the Solaris format be okay?

It could be noticed that there are actually at least four issues above:
1. tag formatting, 'DT_' prefix not suppressed
2. some missing SUNW_ tags not formatted
3. some missing output information (NB: DT_RUNPATH is already submitted,
   but look at DT_CHECKSUM, DT_RELCOUNT, DT_SYM* and DT_FLAGS*)
4. DT_NULL output format compression using a range ([41-50])

cheers
-- 
Richard PALO

[Elftoolchain-developers] Elftoolchain v0.7.1 is now available

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

Elftoolchain v0.7.1 is now available for download from SourceForge:

  https://sourceforge.net/projects/elftoolchain/files/Sources/elftoolchain-0.7.1/

In brief, this release offers:

- Better support of the DWARF4 format.
- Support for more machine architectures.
- Many bug fixes and improvements.

The release also contains experimental code for:

- A library handling the Portable Executable (PE) format.
- A link editor.

Detailed release notes are available at the URL mentioned above.

Many thanks to the project's supporters for their contributions to the project.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Overdue for a release

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

emaste> A lot of progress has been made since the 0.6.1 release in 2012 and I
emaste> think we're overdue for a new release. Can we plan to have one in
emaste> January?

I will start the release process for a 0.7 release shortly, with a
target of the end of the month for the release.

Regards,
Joseph Koshy

[Elftoolchain-developers] libpe import

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

Hello,

I've just imported `libpe', a library for processing Portable
Executable(PE) objects. It supports very basic parsing, creating
and modifying PE image and currently it's intended as an internal
library for our internal tools like elfcopy(1) and objdump(1).

Example usage:
`elfcopy' can use the libpe library to converting PE objects
to/from ELF objects. `objdump' (to-be-implemented) can use
the library to dump PE object headers and sections.

One reason we need this library is that elfcopy(1) need support
converting FreeBSD loader to EFI format (PE32+) for UEFI booting
support, otherwise it can't replace the very old objcopy(1) in base.

The library's API is partly modeled after our libelf so that
users familiar with libelf(3) API can quickly understand how
to use the libpe(3) API. However the API should be considered
unstable at current stage and maybe subject to change.

Documentation and testsuite for the library is not yet started.

/Kai

Re: [Elftoolchain-developers] Overdue for a release

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

On Mon, Dec 14, 2015 at 8:08 PM, Ed Maste <em...@fr...> wrote:

> ELF Tool Chain is still changing frequently and I suspect most users
> will want to fetch the latest from SVN. That said, on the Sourceforge
> files page it reports that the release tarball is downloaded ~ 20
> times per week.
>
> A lot of progress has been made since the 0.6.1 release in 2012 and I
> think we're overdue for a new release. Can we plan to have one in
> January?
>
>
I fully agree it's about time to release 0.7.0. I'll have time to help with
the
release during Dec and Jan. We can discuss further later about what needs
to be done for the release. In the past it was Koshy manage the release
process and maybe he will have something to say as well.

Thanks,
Kai

[Elftoolchain-developers] Overdue for a release

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

ELF Tool Chain is still changing frequently and I suspect most users
will want to fetch the latest from SVN. That said, on the Sourceforge
files page it reports that the release tarball is downloaded ~ 20
times per week.

A lot of progress has been made since the 0.6.1 release in 2012 and I
think we're overdue for a new release. Can we plan to have one in
January?

- Ed