elftoolchain-developers — Discussion on elftoolchain development.

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

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

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.

 [1]: http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/libelftc/elftc_symbol_table_create.3
 [2]: http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/libelftc/elftc_string_table_create.3

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

Re: [Elftoolchain-developers] Build libelf as a shared library on OpenBSD

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

On Thu, Dec 06, 2012 at 09:14:41PM +0100, Kai Wang wrote:
> On Fri, Dec 07, 2012 at 01:33:34AM +0530, Sunil Nimmagadda wrote:
> > Nevermind, shared library on OpenBSD might be broken. I get a
> > 
> >  elf_begin: Request error: invalid ELF_C_* argument
> > 
> > which doesn't happen with static library.
> 
> Hi,
> 
> I think "invalid ELF_C_* argument" is GNU libelf error message.
> 
> Kai

oops, that's correct, I linked with the GNU library. libelf.so works fine now
on OpenBSD.

Re: [Elftoolchain-developers] Build libelf as a shared library on OpenBSD

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

On Fri, Dec 07, 2012 at 01:33:34AM +0530, Sunil Nimmagadda wrote:
> Nevermind, shared library on OpenBSD might be broken. I get a
> 
>  elf_begin: Request error: invalid ELF_C_* argument
> 
> which doesn't happen with static library.

Hi,

I think "invalid ELF_C_* argument" is GNU libelf error message.

Kai

Re: [Elftoolchain-developers] Build libelf as a shared library on OpenBSD

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

Nevermind, shared library on OpenBSD might be broken. I get a

 elf_begin: Request error: invalid ELF_C_* argument

which doesn't happen with static library.

[Elftoolchain-developers] Build libelf as a shared library on OpenBSD

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

Hello,

OpenBSD's bsd.lib.mk requires both SHLIB_MAJOR and SHLIB_MINOR to be
defined for building shared library. NOPIC on OpenBSD suppress PIC
versions as well as shared libraries.

Earlier....
make -n | fgrep shared

with this diff...
make -n | fgrep shared
cc -shared -fpic  -o libelf.so.1.0  `lorder elf.so elf_begin.so
elf_cntl.so elf_end.so elf_errmsg.so elf_errno.so elf_data.so
elf_fill.so elf_flag.so elf_getarhdr.so elf_getarsym.so elf_getbase.so
elf_getident.so elf_hash.so elf_kind.so elf_memory.so elf_next.so
elf_open.so elf_rand.so elf_rawfile.so elf_phnum.so elf_shnum.so
elf_shstrndx.so elf_scn.so elf_strptr.so elf_update.so elf_version.so
gelf_cap.so gelf_checksum.so gelf_dyn.so gelf_ehdr.so gelf_getclass.so
gelf_fsize.so gelf_move.so gelf_phdr.so gelf_rel.so gelf_rela.so
gelf_shdr.so gelf_sym.so gelf_syminfo.so gelf_symshndx.so gelf_xlate.so
libelf_align.so libelf_allocate.so libelf_ar.so libelf_ar_util.so
libelf_checksum.so libelf_data.so libelf_ehdr.so libelf_extended.so
libelf_memory.so libelf_open.so libelf_phdr.so libelf_shdr.so
libelf_xlate.so libelf_fsize.so libelf_msize.so libelf_convert.so|tsort
-q`

Comments?

Index: libelf/Makefile
===================================================================
--- libelf/Makefile	(revision 2710)
+++ libelf/Makefile	(working copy)
@@ -66,6 +66,7 @@
 CLEANFILES=	${GENSRCS}
 
 SHLIB_MAJOR=	1
+SHLIB_MINOR=	0
 
 WARNS?=	6
 
Index: mk/os.OpenBSD.mk
===================================================================
--- mk/os.OpenBSD.mk	(revision 2710)
+++ mk/os.OpenBSD.mk	(working copy)
@@ -6,4 +6,4 @@
 MKTESTS?=	no		# Enable the test suites.
 MKNOWEB?=	no		# Build literate programs.
 
-NOPIC?=	yes
+#NOPIC?=	yes

Re: [Elftoolchain-developers] [PATCH] define EM_AMD64 as a synonym for EM_X86_64

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

> I couldn't compile libelf on amd64 machine running OpenBSD. LIBELF_ARCH
> expands to EM_AMD64 on OpenBSD amd64 architecture which isn't listed in
> elfdefinitions.h. The compilation error...

On which version of OpenBSD did you notice the error?

>From what I can see, OpenBSD has used EM_AMD64 since 2004 at least:
see http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/exec_elf.h.diff?r1=1.38;r2=1.39;f=h.

The elftoolchain sources build fine on OpenBSD 5.0 as of the writing.

Regards,
Joseph Koshy

[Elftoolchain-developers] [PATCH] define EM_AMD64 as a synonym for EM_X86_64

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

Hello,

I couldn't compile libelf on amd64 machine running OpenBSD. LIBELF_ARCH
expands to EM_AMD64 on OpenBSD amd64 architecture which isn't listed in
elfdefinitions.h. The compilation error...

cc -pipe -g  -I. -I/home/sunil/trunk/libelf -I/home/sunil/trunk/libelf/../common -g  -c /home/sunil/trunk/libelf/elf.c -o elf.o
/home/sunil/trunk/libelf/elf.c:34: error: 'EM_AMD64' undeclared here (not in a function)
*** Error 1 in /home/sunil/trunk/libelf (<bsd.lib.mk>:37 'elf.o': @cc -pipe -g  -I. -I/home/sunil/trunk/libelf -I/home/sunil/trunk/libelf/.....)

This patch defines EM_AMD64 as a synonym for EM_X86_64...

diff -up trunk/common/elfdefinitions.h elftoolchain/common/elfdefinitions.h
--- trunk/common/elfdefinitions.h	Sat Nov 24 23:59:05 2012
+++ elftoolchain/common/elfdefinitions.h	Sat Nov 24 23:59:40 2012
@@ -600,6 +600,8 @@ _ELF_DEFINE_EM(EM_ST100,            60,					\
 _ELF_DEFINE_EM(EM_TINYJ,            61,					\
 	"Advanced Logic Corp. TinyJ embedded processor family")		\
 _ELF_DEFINE_EM(EM_X86_64,           62, "AMD x86-64 architecture")	\
+_ELF_DEFINE_EM(EM_AMD64,            EM_X86_64,				\
+	"AMD x86-64 architecture")					\
 _ELF_DEFINE_EM(EM_PDSP,             63, "Sony DSP Processor")		\
 _ELF_DEFINE_EM(EM_PDP10,            64,					\
 	"Digital Equipment Corp. PDP-10")				\

Re: [Elftoolchain-developers] Support for debug_types section?

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

Hello,

The ".debug_types" in the source code is indeed a typo. It should be
".debug_typenames". The DWARF4 .debug_types section is not yet
supported by this libdwarf implementation, but we have plans to add
support for it in the near future.

Thanks for pointing this out.

Best Regards,
Kai

On Fri, Nov 23, 2012 at 05:53:21PM +0100, Sebastian Meyer wrote:
> Hello Developers,
> 
> I am using your libdwarf (0.6.1) in some proof-of-concept code to parse Dwarf debug info.
> While it works quite nice my "normal" Dwarf3&4 binaries, I run into trouble with the debug_types section (If I force the creation with g++-4.7 -gdwarf-4 -fdebug-types-section).
> 
> My question: Is it possible you do not yet support that section?
> Do you plan to support it? If so: How & when?
> Or is my binary just broken (it's a very minimal example with forced debug_types section).
> 
> What I did seems correct to me:
> > rc = dwarf_init(fd, DW_DLC_READ, NULL, NULL, &dbg, &de);
> > check_rc("dwarf_init", rc, true);
> >
> > rc = dwarf_get_types(dbg, &types, &count, &de);
> > check_rc("dwarf_get_types", rc, false);
> >
> > printf("Got %lli elements\n", count);
> > if(count > 0) {
> >     for(int i = 0; i < count; i++) {
> >         rc = dwarf_typename(types[i], &str, &de);
> >         if(rc != DW_DLV_OK) str = "[invalid]";
> >         printf("Type #%i is %s\n", i, str);
> >     }
> > }
> 
> Output -- every . is an invalid char (like 0x004):
> > Type #0 is �
> > Type #1 is 
> > Type #2 is L
..
> > Type #3 is 
> ...
> > Type #11 is 
> > Type #12 is .int
> > Type #13 is 
> > Type #14 is w
> > Type #15 is .    ...	

> > Type #16 is U
> 
> According to the docs the function should be used with the ".debug_typename" section, but according to the source it works on the ".debug_types"...
> 
> Note: The SGI libdwarf seems to support the debug_types section since version 20111030.
> Though I didn't try it out on my example (I can do that next week, if you want to ;)).
> 
> 
> Thanks for any hints to what I might be missing (& thanks for the library :)
> Sebastian
> 
> -------------------------------------- Sebastian Meyer -------------
> AbsInt Angewandte Informatik GmbH      Email: me...@Ab...
> Science Park 1                         Tel:   +49-681-38360-58
> 66123 Saarbrücken                      Fax:   +49-681-38360-20
> GERMANY                                WWW:   http://www.AbsInt.com
> --------------------------------------------------------------------
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

[Elftoolchain-developers] Support for debug_types section?

[Sebastian M. <me...@ab...>]

Hello Developers,

I am using your libdwarf (0.6.1) in some proof-of-concept code to parse Dwarf debug info.
While it works quite nice my "normal" Dwarf3&4 binaries, I run into trouble with the debug_types section (If I force the creation with g++-4.7 -gdwarf-4 -fdebug-types-section).

My question: Is it possible you do not yet support that section?
Do you plan to support it? If so: How & when?
Or is my binary just broken (it's a very minimal example with forced debug_types section).

What I did seems correct to me:
> rc = dwarf_init(fd, DW_DLC_READ, NULL, NULL, &dbg, &de);
> check_rc("dwarf_init", rc, true);
>
> rc = dwarf_get_types(dbg, &types, &count, &de);
> check_rc("dwarf_get_types", rc, false);
>
> printf("Got %lli elements\n", count);
> if(count > 0) {
>     for(int i = 0; i < count; i++) {
>         rc = dwarf_typename(types[i], &str, &de);
>         if(rc != DW_DLV_OK) str = "[invalid]";
>         printf("Type #%i is %s\n", i, str);
>     }
> }

Output -- every . is an invalid char (like 0x004):
> Type #0 is �
> Type #1 is 
> Type #2 is L
..
> Type #3 is 
...
> Type #11 is 
> Type #12 is .int
> Type #13 is 
> Type #14 is w
> Type #15 is .    ...	

> Type #16 is U

According to the docs the function should be used with the ".debug_typename" section, but according to the source it works on the ".debug_types"...

Note: The SGI libdwarf seems to support the debug_types section since version 20111030.
Though I didn't try it out on my example (I can do that next week, if you want to ;)).


Thanks for any hints to what I might be missing (& thanks for the library :)
Sebastian

-------------------------------------- Sebastian Meyer -------------
AbsInt Angewandte Informatik GmbH      Email: me...@Ab...
Science Park 1                         Tel:   +49-681-38360-58
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: [Elftoolchain-developers] Using libelf to copy ELF files/add sections

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

> But whenever I run the code, it fails at elf_update() and prints out  “main: elf_update()  failed : cannot write data to file.”

The string 'cannot write data to file' is not one of the strings
returned by the Elftoolchain implementation of elf_errmsg(3).

On the other hand, that string seems to be present in the libelf.so
binary, provided by the "libelf1" package in Ubuntu.

You might want to check the libraries your application is being linked with.

-- Joseph Koshy

[Elftoolchain-developers] Using libelf to copy ELF files/add sections

[MASON, B. <ma...@em...>]

Hello,

I am trying to use the libelf library under Ubuntu to append a new section that will contain executable code to an existing ELF file. Because the program cannot edit its own ELF file at run-time, I decided to create a copy of the ELF file and just add the new section to the copy. This also lets me understand how ELF files work.

I believe I have successfully copied the PHDR and EHDR correctly (using readelf, the EHDR and PHDR files between the ELF I have originally and the one I copied are the same with the exception of my copied ELF saying the section index of the string table is 0). I've come across a problem copying sections from one ELF file to another. From my understanding, each section in an ELF file can hold more than 1 data descriptor. I can use elf_getdata() to iterate and copy each data descriptor within each section, and use elf_nextscn() to iterate across every section in a particular elf file. Using the code below, I can compile just fine. But whenever I run the code, it fails at elf_update() and prints out "main: elf_update()  failed : cannot write data to file." into the console. I'm stumped at what could be causing the problem.

               Elf *e1,*e2;
Elf_Scn *scn1,*scn2;
Elf_Data *data1,*data2;
GElf_Ehdr ehdr1,*ehdr2;
GElf_Phdr phdr1,phdr2;
GElf_Shdr shdr1,shdr2;

... open/create ELF files, copy EHDR, copy PHDR ...

int sndx=1;
                scn1 = NULL;
                printf("Starting to copy sections...\n");

                while ((scn1 = elf_nextscn (e1, scn1)) != NULL) {

                                if (gelf_getshdr(scn1, &shdr1) != &shdr1)
                                                errx (EXIT_FAILURE, "getshdr()  failed : %s.",elf_errmsg ( -1));
if ((scn2 = elf_newscn(e2)) == NULL) {
errx(EX_SOFTWARE, "elf_newscn() failed: %s.",elf_errmsg(-1));
return 0;
}
if (gelf_getshdr (scn2, &shdr2) != &shdr2)
              errx (EXIT_FAILURE, "getshdr ()  failed : %s.",elf_errmsg ( -1));
memcpy(&shdr2,&shdr1,sizeof(shdr1));

                                data1=NULL;
                                while ((data1=elf_getdata(scn1,data1))!=NULL){
                                                if ((data2 = elf_newdata(scn2)) == NULL)
                                                                errx (EXIT_FAILURE, "elf_newdata () failed: %s." , elf_errmsg (-1));
                                                memcpy(data2,data1,sizeof(*data1));
                                }
                                sndx++;
                }

                printf("Copied %d out of %d sections.\n", sndx, ehdr1.e_shnum);
                if (elf_update(e2, ELF_C_WRITE) < 0) {
                                errx ( EXIT_FAILURE , "elf_update ()  failed : %s.",elf_errmsg ( -1));
                                return 0;
                }

Thanks,
Bryan Mason

[Elftoolchain-developers] v0.6.1 has been released

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

Hello All,

FYI: version 0.6.1 has been released, and may be downloaded from
SourceForge.Net's file release system:

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

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] problem with building elf tool chain on redhat 6.2

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

> I'm trying to compile the elf toolchain on redhat 6.2 and I'm not even
> getting very far in the makefile. I've downloaded the trunk, as of yesterday
> and I ran make. The error I get is
>
> Makefile:5: *** missing separator.  Stop.

> I've tried looking up things that could be causing this, but I'm not very
> familiar with the details of makefiles. Any help would be appreciated.

BSD 'make' is needed to build the sources.

Building the tree on a RedHat operating system is not supported
out-of-the box (yet)---you may therefore need to install other
pre-requisites and/or make source code changes in order to get the
tree to build.

Please see:
 * The file named "INSTALL" at the top of the source tree.
 * http://sourceforge.net/apps/trac/elftoolchain/wiki/BuildingFromSource.

Regards,
Joseph Koshy

[Elftoolchain-developers] problem with building elf tool chain on redhat 6.2

[Steve D. <die...@gm...>]

Hi,

I'm trying to compile the elf toolchain on redhat 6.2 and I'm not even
getting very far in the makefile. I've downloaded the trunk, as of
yesterday and I ran make. The error I get is

Makefile:5: *** missing separator.  Stop.

If I put a tab before it I get

Makefile:5: *** commands commence before first target.  Stop.

I've tried looking up things that could be causing this, but I'm not very
familiar with the details of makefiles. Any help would be appreciated.
Thanks

Re: [Elftoolchain-developers] elftoolchain strip bug

[Michal M. <ak...@ja...>]

On Sun, Aug 12, 2012 at 06:23:18PM +0200, Kai Wang wrote:
> On Sat, Aug 11, 2012 at 06:42:50PM +0200, Michal Mazurek wrote:
> > On Sat, Aug 11, 2012 at 05:17:27PM +0200, Kai Wang wrote:
> > > On Sat, Aug 11, 2012 at 08:53:19AM +0200, Michal Mazurek wrote:
> > > > On Sat, Aug 11, 2012 at 12:18:55AM +0200, Kai Wang wrote:
> > > > > Hi,
> > > > > 
> > > > > On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> > > > > > 
> > > > > > 
> > > > > > Elftoolchain compiles after applying the attached patch, but strip seems
> > > > > > to have a bug. Here is the difference between a binary stripped with gnu
> > > > > > strip, and elftoolchain strip:
> > > > > 
> > > > > Thanks for reporting this bug. Could you please put the binary file
> > > > > you used to test strip somewhere online, or email it to me?
> > > > 
> > > > I uploaded the binary files here (the make program):
> > > > http://akfaew.jasminek.net/crap/elftoolchain/
> > > > 
> > > > make.notstripped - not stripped
> > > > make.elf - stripped with elftoolchain
> > > > make.gnu - stripped with gnu strip
> > > 
> > > Thanks. It should be fixed by r2540. Let me know if it still doesn't
> > > work for you.
> > 
> > Thank you, I managed to build world now, however there is still a difference.
> > Stripping the uploaded binary make.notstripped with gnu strip and elftoolchain
> > strip produces this difference:
> 
> Thanks for the feedback. readelf(1) issue was fixed by r2541. The
> strip(1) different phdr size issue should be fixed by r2542.

Thanks, Bitrig now builds fine. We'd like to replace GNU tools with
elftoolchain. Would you mind releasing the fixed version 0.5.2?

-- 
Michal Mazurek

Re: [Elftoolchain-developers] elftoolchain strip bug

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

On Sat, Aug 11, 2012 at 06:42:50PM +0200, Michal Mazurek wrote:
> On Sat, Aug 11, 2012 at 05:17:27PM +0200, Kai Wang wrote:
> > On Sat, Aug 11, 2012 at 08:53:19AM +0200, Michal Mazurek wrote:
> > > On Sat, Aug 11, 2012 at 12:18:55AM +0200, Kai Wang wrote:
> > > > Hi,
> > > > 
> > > > On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> > > > > Hello,
> > > > > 
> > > > > I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> > > > > 
> > > > > 
> > > > > Elftoolchain compiles after applying the attached patch, but strip seems
> > > > > to have a bug. Here is the difference between a binary stripped with gnu
> > > > > strip, and elftoolchain strip:
> > > > 
> > > > Thanks for reporting this bug. Could you please put the binary file
> > > > you used to test strip somewhere online, or email it to me?
> > > 
> > > I uploaded the binary files here (the make program):
> > > http://akfaew.jasminek.net/crap/elftoolchain/
> > > 
> > > make.notstripped - not stripped
> > > make.elf - stripped with elftoolchain
> > > make.gnu - stripped with gnu strip
> > 
> > Thanks. It should be fixed by r2540. Let me know if it still doesn't
> > work for you.
> 
> Thank you, I managed to build world now, however there is still a difference.
> Stripping the uploaded binary make.notstripped with gnu strip and elftoolchain
> strip produces this difference:

Thanks for the feedback. readelf(1) issue was fixed by r2541. The
strip(1) different phdr size issue should be fixed by r2542.

Kai

Re: [Elftoolchain-developers] elftoolchain strip bug

[Michal M. <ak...@ja...>]

On Sat, Aug 11, 2012 at 05:17:27PM +0200, Kai Wang wrote:
> On Sat, Aug 11, 2012 at 08:53:19AM +0200, Michal Mazurek wrote:
> > On Sat, Aug 11, 2012 at 12:18:55AM +0200, Kai Wang wrote:
> > > Hi,
> > > 
> > > On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> > > > Hello,
> > > > 
> > > > I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> > > > 
> > > > 
> > > > Elftoolchain compiles after applying the attached patch, but strip seems
> > > > to have a bug. Here is the difference between a binary stripped with gnu
> > > > strip, and elftoolchain strip:
> > > 
> > > Thanks for reporting this bug. Could you please put the binary file
> > > you used to test strip somewhere online, or email it to me?
> > 
> > I uploaded the binary files here (the make program):
> > http://akfaew.jasminek.net/crap/elftoolchain/
> > 
> > make.notstripped - not stripped
> > make.elf - stripped with elftoolchain
> > make.gnu - stripped with gnu strip
> 
> Thanks. It should be fixed by r2540. Let me know if it still doesn't
> work for you.

Thank you, I managed to build world now, however there is still a difference.
Stripping the uploaded binary make.notstripped with gnu strip and elftoolchain
strip produces this difference:

--- dump.elf    Wed Aug  8 11:28:00 2012
+++ dump.gnu    Wed Aug  8 11:27:57 2012
@@ -19,16 +19,16 @@
 program header:
 
 entry: 0
        p_type: PT_PHDR
        p_offset: 64
        p_vaddr: 0x400040
        p_paddr: 0x400040
-       p_filesz: 672
-       p_memsz: 672
+       p_filesz: 560
+       p_memsz: 560
        p_flags: PF_X|PF_R
        p_align: 8
 
 entry: 1
        p_type: PT_INTERP
        p_offset: 736
        p_vaddr: 0x4002e0

>From the output of hexdump it seems this is the only difference, and thus might be a bug:
$ diff hex.elf hex.gnu                                                                                                                                                                                                                           
7c7
< 00000060  a0 02 00 00 00 00 00 00  a0 02 00 00 00 00 00 00  |................|
---
> 00000060  30 02 00 00 00 00 00 00  30 02 00 00 00 00 00 00  |0.......0.......|



This warning generated by clang might also interest you:

===> readelf
clang -O3 -pipe -pipe  -I. -I/usr/ports/pobj/bitrig-elftoolchain-2540/elftoolchain-2540/readelf -I../common -I../libdwarf -I../libelf -I../libelftc -I/usr/local/include   -nostdinc -idirafter /usr/include -c readelf.c
readelf.c:6135:44: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand]
        if ((re->options & RE_VV) || (re->options && RE_S))
                                                  ^  ~~~~
readelf.c:6135:44: note: use '&' for a bitwise operation
        if ((re->options & RE_VV) || (re->options && RE_S))
                                                  ^~
                                                  &       
readelf.c:6135:44: note: remove constant to silence this warning
        if ((re->options & RE_VV) || (re->options && RE_S))
                                                 ~^~~~~~~
1 warning generated.

-- 
Michal Mazurek

Re: [Elftoolchain-developers] elftoolchain strip bug

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

On Sat, Aug 11, 2012 at 08:53:19AM +0200, Michal Mazurek wrote:
> On Sat, Aug 11, 2012 at 12:18:55AM +0200, Kai Wang wrote:
> > Hi,
> > 
> > On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> > > Hello,
> > > 
> > > I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> > > 
> > > 
> > > Elftoolchain compiles after applying the attached patch, but strip seems
> > > to have a bug. Here is the difference between a binary stripped with gnu
> > > strip, and elftoolchain strip:
> > 
> > Thanks for reporting this bug. Could you please put the binary file
> > you used to test strip somewhere online, or email it to me?
> 
> I uploaded the binary files here (the make program):
> http://akfaew.jasminek.net/crap/elftoolchain/
> 
> make.notstripped - not stripped
> make.elf - stripped with elftoolchain
> make.gnu - stripped with gnu strip

Thanks. It should be fixed by r2540. Let me know if it still doesn't
work for you.

Kai

Re: [Elftoolchain-developers] elftoolchain strip bug

[Michal M. <ak...@ja...>]

On Sat, Aug 11, 2012 at 12:18:55AM +0200, Kai Wang wrote:
> Hi,
> 
> On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> > Hello,
> > 
> > I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> > 
> > 
> > Elftoolchain compiles after applying the attached patch, but strip seems
> > to have a bug. Here is the difference between a binary stripped with gnu
> > strip, and elftoolchain strip:
> 
> Thanks for reporting this bug. Could you please put the binary file
> you used to test strip somewhere online, or email it to me?

I uploaded the binary files here (the make program):
http://akfaew.jasminek.net/crap/elftoolchain/

make.notstripped - not stripped
make.elf - stripped with elftoolchain
make.gnu - stripped with gnu strip

-- 
Michal Mazurek

Re: [Elftoolchain-developers] elftoolchain strip bug

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

Hi,

On Fri, Aug 10, 2012 at 02:16:28PM +0200, Michal Mazurek wrote:
> Hello,
> 
> I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.
> 
> 
> Elftoolchain compiles after applying the attached patch, but strip seems
> to have a bug. Here is the difference between a binary stripped with gnu
> strip, and elftoolchain strip:

Thanks for reporting this bug. Could you please put the binary file
you used to test strip somewhere online, or email it to me?

Thanks,
Kai

[Elftoolchain-developers] elftoolchain strip bug

[Michal M. <ak...@ja...>]

Hello,

I'm trying to get elftoolchain to work on Bitrig, an OpenBSD fork.


Elftoolchain compiles after applying the attached patch, but strip seems
to have a bug. Here is the difference between a binary stripped with gnu
strip, and elftoolchain strip:

$ diff dump.elf dump.gnu
73,77c73,77
<       p_offset: 120128
<       p_vaddr: 0x81d540
<       p_paddr: 0x81d540
<       p_filesz: 0
<       p_memsz: 0
---
>       p_offset: 119216
>       p_vaddr: 0x71d1b0
>       p_paddr: 0x71d1b0
>       p_filesz: 912
>       p_memsz: 912
83,87c83,87
<       p_offset: 119216
<       p_vaddr: 0x71d1b0
<       p_paddr: 0x71d1b0
<       p_filesz: 912
<       p_memsz: 10504
---
>       p_offset: 120128
>       p_vaddr: 0x81d540
>       p_paddr: 0x81d540
>       p_filesz: 0
>       p_memsz: 9592

- two sections are swapped, and their p_memsz are wrong. This results in
a segfault.

After stripping the binary a second time there is another difference:
$ diff dump.elf dump.elfelf
74,75c74,75
<       p_vaddr: 0x81d540
<       p_paddr: 0x81d540
---
>       p_vaddr: 0x71d540
>       p_paddr: 0x71d540
- running this binary results in an Abort trap.


The same applies to OpenBSD.

-- 
Michal Mazurek

Re: [Elftoolchain-developers] ld(1) status and roadmap?

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

On Wed, Jul 25, 2012 at 10:45:55PM +0200, Erik Cederstrand wrote:
> Hi guys,
> 
> Looking at the commit messages, it seems there's a fair amount of development on the linker. What's the status of the linker currently? Do you have a roadmap for the development?

Currently the linker support "-static" linking of simple program under
i386 and amd64.  We don't have a roadmap yet. The next step is to
implement generating dynamically linked objects.

Thanks,
Kai

[Elftoolchain-developers] ld(1) status and roadmap?

[Erik C. <er...@ce...>]

Hi guys,

Looking at the commit messages, it seems there's a fair amount of development on the linker. What's the status of the linker currently? Do you have a roadmap for the development?

Thanks,
Erik

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

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

On Thu, Apr 12, 2012 at 04:24:13PM +0530, Sunil Nimmagadda wrote:
> Here is an attempt to implement solution for this ticket. Tested with
> limited knowledge about elf.

Modified patch committed in r2490. Thanks!

Kai

Re: [Elftoolchain-developers] Fix seg fault in readelf

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

On Thu, Apr 12, 2012 at 02:50:52PM +0530, Sunil Nimmagadda wrote:
> Hello,
> 
> According to elf_getdata(3) d_buf can be NULL. This diff checks for
> d_buf while doing a str_dump. This fixes a crash when dumping .bss in
> readelf.

Modified patch committed in r2489. Thanks!

Kai