elftoolchain-developers — Discussion on elftoolchain development.

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

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

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

> e.s> Would it be possible to share a simple C script which opens, edits and
> e.s> then writes out a modified elf file using libelf?
>
> There are a few such examples in libelf's test suite; please look for
> the constant "ELF_C_RDWR" in:
>
>     http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/test/libelf/tset/elf_update/update.m4
>

Thanks for the pointer.  Attached is my attempt to re-write one of the
test cases into an external C file to allow extending a data section in
an existing elf file.  The resulting script fails with the following...

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

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

Thanks -- Eric

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

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

e.s> Would it be possible to share a simple C script which opens, edits and
e.s> then writes out a modified elf file using libelf?

There are a few such examples in libelf's test suite; please look for
the constant "ELF_C_RDWR" in:

    http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/test/libelf/tset/elf_update/update.m4

Regards,
Koshy

Re: [Elftoolchain-developers] Add support for demangling gcc's local-source-name mangling

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

On Fri, Oct 14, 2011 at 01:25:22PM -0400, Reid Kleckner wrote:
> This is useful for demangling the names of static functions.  I used
> Google's open source demangler as a reference:
> http://code.google.com/p/google-glog/source/browse/trunk/src/demangle.cc
> 
> gcc mangles the function "static int foo(int)" into _ZL3fooi, which
> previously elftoolchain was unable to demangle.

Thanks. Committed in r2014.

Kai

Re: [Elftoolchain-developers] Memory leak in elftc_demangle

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

On Fri, Oct 14, 2011 at 02:46:17PM -0400, Reid Kleckner wrote:
> The patch attached fixes it.

Thanks. Committed in r2015.

Kai

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

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

Would it be possible to share a simple C script which opens, edits and
then writes out a modified elf file using libelf?

Thanks -- Eric

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

> After changeset [1712], libelf supports "in-place" updation of ELF
> objects opened in ELF_C_RDWR mode.
>
> This feature required a number of changes to the implementation of
> `elf_update()`.  While I have added a number of test cases to the
> libelf test suite to verify that libelf continues to work as expected,
> there could still be bugs lurking in the code.
>
> Please do let me know if you notice any regressions, or if you have
> suggestions for additional test coverage.
>
> Thanks,
> Koshy
>
> Quick Links:
>
>  * Source Changes:
>    - http://sourceforge.net/apps/trac/elftoolchain/changeset/1712
>    - http://sourceforge.net/apps/trac/elftoolchain/changeset/1693
>  * Current test cases
>    - http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/test/libelf/tset/elf_update/update.m4
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

[Elftoolchain-developers] Memory leak in elftc_demangle

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

The patch attached fixes it.

Reid

Index: libelftc/elftc_demangle.c
===================================================================
--- libelftc/elftc_demangle.c	(revision 2013)
+++ libelftc/elftc_demangle.c	(working copy)
@@ -31,6 +31,7 @@
 #include <errno.h>
 #include <libelf.h>
 #include <libelftc.h>
+#include <stdlib.h>
 #include <string.h>

 #include "_libelftc.h"
@@ -96,12 +97,14 @@
 	}

 	if (buffer == NULL || bufsize < strlen(rlt) + 1) {
+		free(rlt);
 		errno = ENAMETOOLONG;
 		return (-1);
 	}

 	strncpy(buffer, rlt, bufsize);
 	buffer[bufsize - 1] = '\0';
+	free(rlt);

 	return (0);
 }

[Elftoolchain-developers] Add support for demangling gcc's local-source-name mangling

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

This is useful for demangling the names of static functions.  I used
Google's open source demangler as a reference:
http://code.google.com/p/google-glog/source/browse/trunk/src/demangle.cc

gcc mangles the function "static int foo(int)" into _ZL3fooi, which
previously elftoolchain was unable to demangle.

The short patch is attached and pasted inline, since every one seems
to have different preferences.

Reid


Index: libelftc/libelftc_dem_gnu3.c
===================================================================
--- libelftc/libelftc_dem_gnu3.c	(revision 2013)
+++ libelftc/libelftc_dem_gnu3.c	(working copy)
@@ -120,6 +120,7 @@
 		    const char *, size_t, const char *, size_t);
 static int	cpp_demangle_read_function(struct cpp_demangle_data *, int *,
 		    struct vector_type_qualifier *);
+static int	cpp_demangle_local_source_name(struct cpp_demangle_data *ddata);
 static int	cpp_demangle_read_local_name(struct cpp_demangle_data *);
 static int	cpp_demangle_read_name(struct cpp_demangle_data *);
 static int	cpp_demangle_read_nested_name(struct cpp_demangle_data *);
@@ -2711,10 +2712,43 @@
 	if (ELFTC_ISDIGIT(*ddata->cur) != 0)
 		return (cpp_demangle_read_sname(ddata));

+	/* local source name */
+	if (*ddata->cur == 'L')
+		return (cpp_demangle_local_source_name(ddata));
+
 	return (1);
 }

+/*
+ * Read local source name.
+ *
+ * References:
+ *   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
+ *   http://gcc.gnu.org/viewcvs?view=rev&revision=124467
+ */
 static int
+cpp_demangle_local_source_name(struct cpp_demangle_data *ddata)
+{
+	/* L */
+	if (ddata == NULL || *ddata->cur != 'L')
+		return (0);
+	++ddata->cur;
+
+	/* source name */
+	if (!cpp_demangle_read_sname(ddata))
+		return (0);
+
+	/* discriminator */
+	if (*ddata->cur == '_') {
+		++ddata->cur;
+		while (ELFTC_ISDIGIT(*ddata->cur) != 0)
+			++ddata->cur;
+	}
+
+	return (1);
+}
+
+static int
 cpp_demangle_read_v_offset(struct cpp_demangle_data *ddata)
 {

[Elftoolchain-developers] Fwd: Static PIC or shared library builds on Linux

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

> I'm on Ubuntu 10.04, and I want to link libelf, libdwarf, and libelftc
> into a shared library I'm building for symbol lookup. I tried editing
> mk/os.Linux to set MKPIC to "yes", but things seem to be going very
> wrong.

> Each .c file gets turned into a .so file, and I end up with a
> lib(elf|dwarf)_pic.a file. There happens to be a libdwarf.c file, so
> when the build system tries to link addr2line with -ldwarf, it picks
> up libdwarf.so instead of libdwarf.a, and the build fails.

> I think for my purposes I can just life libdwarf_pic.a, libelf_pic.a,
> and libelftc_pic.a, but it would be nice if the build didn't fail.

The ruleset that is part of the "pmake" package on Ubuntu does not
appear to handle shared library creation very well.

I needed the following changes to successfully build a .so:

First, a hack/patch was needed for "/usr/share/mk/bsd.lib.mk":

--- bsd.lib.mk--        2010-01-05 12:01:04.000000000 +0530
+++ bsd.lib.mk  2011-09-30 15:20:29.986766086 +0530
@@ -114,9 +114,9 @@
 # Platform-independent linker flags for ELF shared libraries
 .if ${OBJECT_FMT} == "ELF"
 SHLIB_SOVERSION=${SHLIB_MAJOR}
-SHLIB_SHFLAGS=-soname lib${LIB}.so.${SHLIB_SOVERSION}
-SHLIB_LDSTARTFILE= ${DESTDIR}/usr/lib/crtbeginS.o
-SHLIB_LDENDFILE= ${DESTDIR}/usr/lib/crtendS.o
+SHLIB_SHFLAGS=-Wl,-soname=lib${LIB}.so.${SHLIB_SOVERSION}
+#SHLIB_LDSTARTFILE= ${DESTDIR}/usr/lib/crtbeginS.o
+#SHLIB_LDENDFILE= ${DESTDIR}/usr/lib/crtendS.o
 .endif

 CFLAGS+=       ${COPTS}
@@ -256,24 +256,22 @@
 .if defined(DESTDIR)
       $(CC) -shared ${SHLIB_SHFLAGS} -o ${.TARGET} \
           ${SHLIB_LDSTARTFILE} \
-           --whole-archive lib${LIB}_pic.a \
+           -Wl,--whole-archive lib${LIB}_pic.a \
           -nostdlib -L${DESTDIR}${LIBDIR} -R${LIBDIR} \
-           --no-whole-archive ${LDADD} \
+           -Wl,--no-whole-archive ${LDADD} \
           ${SHLIB_LDENDFILE}
 .else
       $(CC) -shared ${SHLIB_SHFLAGS} -o ${.TARGET} \
           ${SHLIB_LDSTARTFILE} \
-           --whole-archive lib${LIB}_pic.a --no-whole-archive ${LDADD} \
-           ${SHLIB_LDENDFILE}
+           -Wl,--whole-archive lib${LIB}_pic.a -Wl,--no-whole-archive \
+           ${LDADD} ${SHLIB_LDENDFILE}
 .endif
-.if ${OBJECT_FMT} == "ELF"
       rm -f lib${LIB}.so.${SHLIB_MAJOR}
       ln -s lib${LIB}.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
           lib${LIB}.so.${SHLIB_MAJOR}
       rm -f lib${LIB}.so
       ln -s lib${LIB}.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
           lib${LIB}.so
-.endif

 LOBJS+=                ${LSRCS:.c=.ln} ${SRCS:M*.c:.c=.ln}
 LLIBS?=                -lc


You also need to set the SHLIB_{MAJOR,MINOR}, OBJECT_FMT and MKPIC
knobs in the library Makefiles. For example, for libelf:

diff --git a/trunk/libelf/Makefile b/trunk/libelf/Makefile
index 6fb27d0..b903f1c 100644
--- a/trunk/libelf/Makefile
+++ b/trunk/libelf/Makefile
@@ -155,4 +155,9 @@ libelf_convert.c:   elf_types.m4 libelf_convert.m4
 libelf_fsize.c:                elf_types.m4 libelf_fsize.m4
 libelf_msize.c:                elf_types.m4 libelf_msize.m4

+MKPIC= yes
+SHLIB_MAJOR=1
+SHLIB_MINOR=0
+OBJECT_FMT=ELF
+
 .include "${TOP}/mk/elftoolchain.lib.mk"


With these two changes, "pmake" should build a working
"lib{LIB}.so.1.0" file:

 % pmake
 ...snip...
 building shared elf library (version 1.0)
 cc -shared -Wl,-soname=libelf.so.1 -o libelf.so.1.0 \
   -Wl,--whole-archive libelf_pic.a -Wl,--no-whole-archive
 rm -f libelf.so.1
 ln -s libelf.so.1.0 libelf.so.1
 rm -f libelf.so
 ln -s libelf.so.1.0 libelf.so


Notes:

* NetBSD [bmake][1] could possibly be an alternative "BSD make" for
 GNU/Linux, but I haven't checked it out yet.

 [1]: http://www.crufty.net/help/sjg/bmake.h

* The other thing to keep in mind is that the base Ubuntu system
 ships with a "libelf.so.1"; you would want to ensure that
 applications compiled against our headers don't use this library
 at runtime.

HTH,
Koshy

[Elftoolchain-developers] Static PIC or shared library builds on Linux

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

I'm on Ubuntu 10.04, and I want to link libelf, libdwarf, and libelftc
into a shared library I'm building for symbol lookup.  I tried editing
mk/os.Linux to set MKPIC to "yes", but things seem to be going very
wrong.  Each .c file gets turned into a .so file, and I end up with a
lib(elf|dwarf)_pic.a file.  There happens to be a libdwarf.c file, so
when the build system tries to link addr2line with -ldwarf, it picks
up libdwarf.so instead of libdwarf.a, and the build fails.

I think for my purposes I can just life libdwarf_pic.a, libelf_pic.a,
and libelftc_pic.a, but it would be nice if the build didn't fail.

Reid

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

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

After changeset [1712], libelf supports "in-place" updation of ELF
objects opened in ELF_C_RDWR mode.

This feature required a number of changes to the implementation of
`elf_update()`.  While I have added a number of test cases to the
libelf test suite to verify that libelf continues to work as expected,
there could still be bugs lurking in the code.

Please do let me know if you notice any regressions, or if you have
suggestions for additional test coverage.

Thanks,
Koshy

Quick Links:

 * Source Changes:
   - http://sourceforge.net/apps/trac/elftoolchain/changeset/1712
   - http://sourceforge.net/apps/trac/elftoolchain/changeset/1693
 * Current test cases
   - http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/test/libelf/tset/elf_update/update.m4

Re: [Elftoolchain-developers] elf_update breaks elf executable

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

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

>> I'm trying to modify the .text section of an existing elf executable,
>> however even the simplest elf_begin, elf_update, elf_end sequence
>> results in a non-functioning executable elf file.
>
> This is most likely a known bug [1]; the ELF_C_RDWR case has never
> worked properly.
>
> The (rather ugly) workaround is to create a new ELF object by copying
> over contents from the old one.
>

Thanks for the reply and the workaround.

I've since switched to using libbfd (part of gnu binutils [1]), which
although more mature doesn't as conveniently expose general purpose
functions for elf manipulation, and I finally found it easiest to
implemented this functionality myself in common lisp [2].

Thanks -- Eric

Footnotes: 
[1]  http://www.gnu.org/software/binutils/

[2]  http://cs.unm.edu/~eschulte/research/cl-elf/

Re: [Elftoolchain-developers] elf_update breaks elf executable

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

> I'm trying to modify the .text section of an existing elf executable,
> however even the simplest elf_begin, elf_update, elf_end sequence
> results in a non-functioning executable elf file.

This is most likely a known bug [1]; the ELF_C_RDWR case has never
worked properly.

The (rather ugly) workaround is to create a new ELF object by copying
over contents from the old one.

Refs:
 1: http://sourceforge.net/apps/trac/elftoolchain/ticket/269

-- Koshy

[Elftoolchain-developers] elf_update breaks elf executable

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

Hi,

I'm trying to modify the .text section of an existing elf executable,
however even the simplest elf_begin, elf_update, elf_end sequence
results in a non-functioning executable elf file.

For example, with an executable compiled from the following very simple
hello world c program.

Re: [Elftoolchain-developers] nm(1) test cases on case sensitive file systems

[David R. <da...@si...>]

Hi,
I was able to successfully check out the trunk with your changes.

Thank you.

--
David P. Reese, Jr.



On Jan 23, 2011, at 2:50 AM, Hyogeol Lee wrote:

> Hello,
> 
> 
> I just fixed test case file name in r1382.
> 
> Would you confirm that works in your system?
> 
> FYI, if you check out branch tree, it cause problem again. I did not
> fix files in branch, so check out trunk only if you has problem on
> branch.
> 
> 
> Best Regards,
> Hyogeol Lee
> 
> 2011/1/17 Hyogeol Lee <hyo...@gm...>:
>> Hi,
>> 
>> 
>> Sorry for late.
>> 
>> It can be problem on case insentitive FS.
>> 
>> I'll fix it to next weekend.
>> 
>> Thanks for feedback.
>> 
>> 
>> Regards,
>> Hyogeol Lee
>> 
>> 
>> 2011/1/13 David P. Reese, Jr. <da...@si...>:
>>> Hi,
>>> Just for kicks, I'm interested in trying to get this working on OS X and I've managed to hit a stumbling block even before my SVN checkout completed.  It seems that there are test cases for nm whose files only differ by case.  This causes problems when checking out on an HFS+ which is case insensitive, yet case preserving.
>>> 
>>> Is this something that you feel is worth fixing for the sake of those of us on OS X?  I imagine this also has an impact on Windows with NTFS, but I'm not sure if it causes errors on the various Windows SVN clients.
>>> 
>>> Thank you.
>>> 
>>> --
>>> David P. Reese, Jr.
>>> da...@si...
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Elftoolchain-developers mailing list
>>> Elf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>>> 
>> 

Re: [Elftoolchain-developers] nm(1) test cases on case sensitive file systems

[Hyogeol L. <hyo...@gm...>]

Hello,


I just fixed test case file name in r1382.

Would you confirm that works in your system?

FYI, if you check out branch tree, it cause problem again. I did not
fix files in branch, so check out trunk only if you has problem on
branch.


Best Regards,
Hyogeol Lee

2011/1/17 Hyogeol Lee <hyo...@gm...>:
> Hi,
>
>
> Sorry for late.
>
> It can be problem on case insentitive FS.
>
> I'll fix it to next weekend.
>
> Thanks for feedback.
>
>
> Regards,
> Hyogeol Lee
>
>
> 2011/1/13 David P. Reese, Jr. <da...@si...>:
>> Hi,
>> Just for kicks, I'm interested in trying to get this working on OS X and I've managed to hit a stumbling block even before my SVN checkout completed.  It seems that there are test cases for nm whose files only differ by case.  This causes problems when checking out on an HFS+ which is case insensitive, yet case preserving.
>>
>> Is this something that you feel is worth fixing for the sake of those of us on OS X?  I imagine this also has an impact on Windows with NTFS, but I'm not sure if it causes errors on the various Windows SVN clients.
>>
>> Thank you.
>>
>> --
>> David P. Reese, Jr.
>> da...@si...
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Elftoolchain-developers mailing list
>> Elf...@li...
>> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>>
>

Re: [Elftoolchain-developers] nm(1) test cases on case sensitive file systems

[Hyogeol L. <hyo...@gm...>]

Hi,


Sorry for late.

It can be problem on case insentitive FS.

I'll fix it to next weekend.

Thanks for feedback.


Regards,
Hyogeol Lee


2011/1/13 David P. Reese, Jr. <da...@si...>:
> Hi,
> Just for kicks, I'm interested in trying to get this working on OS X and I've managed to hit a stumbling block even before my SVN checkout completed.  It seems that there are test cases for nm whose files only differ by case.  This causes problems when checking out on an HFS+ which is case insensitive, yet case preserving.
>
> Is this something that you feel is worth fixing for the sake of those of us on OS X?  I imagine this also has an impact on Windows with NTFS, but I'm not sure if it causes errors on the various Windows SVN clients.
>
> Thank you.
>
> --
> David P. Reese, Jr.
> da...@si...
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>

[Elftoolchain-developers] nm(1) test cases on case sensitive file systems

[David P. R. Jr. <da...@si...>]

Hi,
Just for kicks, I'm interested in trying to get this working on OS X and I've managed to hit a stumbling block even before my SVN checkout completed.  It seems that there are test cases for nm whose files only differ by case.  This causes problems when checking out on an HFS+ which is case insensitive, yet case preserving.

Is this something that you feel is worth fixing for the sake of those of us on OS X?  I imagine this also has an impact on Windows with NTFS, but I'm not sure if it causes errors on the various Windows SVN clients.

Thank you.

--
David P. Reese, Jr.
da...@si...

[Elftoolchain-developers] Insert (retrieve) a section into (from) an elf

[陳韋任 <ch...@cs...>]

Hi, all:

  I plan to add some data into an elf file, then retrieve those data
back when running the elf file. I would like to use libelf to get the
job done.

  For adding data into an elf file, I found 'objcopy --add-section
sectionname=filename theElf' can do the same thing without using libelf.
Am I right? Will 'objcopy' update all related entries? Or I have to use
libelf to do it?

  Then for retrieving data within a particular section, I tried to use
those API mentioned in the tutorial "libelf by Example" written by Joseph.
I found the procedure was quite different from my original thought.

  At first, I tended to iterate though the section header table. With
the "sh_name" member in the section header table entry and shstrndx,
I could find the section I want by comparing the section name.

  However, what I done now was iterating though all sections, NOT section
header table, then got associated section table entry and compared the
section name. It's pretty much like the program 4 (listing all section names)
in the tutorial "libelf by Example".

  I don't know if it is the only way to get data in a particular
section. Any suggestion will be appreciated.

Regards,
chenwj

-- 
Wei-Jen Chen (陳韋任)
Programming Language and System Laboratory (EC131)
Department of Computer Science, National Chiao Tung University

Re: [Elftoolchain-developers] windows porting...

[Gorton, R. <Ric...@am...>]

As I read through the compiler warnings, I'm arriving at the opinion that some of these need to remain warnings in a 32-bit environment: uint64_t/Dwarf_Unsigned conversions to Dwarf_Off (== off_t); uint64_t to size_t similarly.  Most of these will only become a problem if the size of the file exceeds 32-bits; this is highly improbable for my target usage, but may be pertinent for others (perhaps 32-bit Linux, with very large executables), so I'm not going to fiddle with those.

I hope to post a patch to the list later today.

Rick

Re: [Elftoolchain-developers] windows porting...

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

> As for the existing makefiles, I'll observe that gnu make (under
> ubuntu/64-bit) objects to ".include <bsd.subdir.mk>" in the top level
> makefile.

That is not surprising --- our Makefiles use BSD make syntax.

See: http://crufty.net/help/sjg/bmake.html.

-- Koshy

Re: [Elftoolchain-developers] windows porting...

[Gorton, R. <Ric...@am...>]

I'm doing a native port to visual studio; we've got a build environment which uses a tool called bjam to do the compilations.  As for the existing makefiles, I'll observe that gnu make (under ubuntu/64-bit) objects to ".include <bsd.subdir.mk>" in the top level makefile.  I haven't looked at the tests at all.

Rick

-----Original Message-----
From: ko...@un... [mailto:ko...@un...] On Behalf Of Joseph Koshy
Sent: Saturday, October 09, 2010 1:35 AM
To: Gorton, Richard
Cc: elf...@li...
Subject: Re: [Elftoolchain-developers] windows porting...

> I've got a need to port elftoolchain to Windows, and am in the
  process of doing so.

Best of luck!  Our current porting targets are open-source POSIX
systems. To the best of our knowledge, you would be the first person
attempting a Windows(R) port.

Changes that improve our code's portability would be welcome.

Its also fair to point out upfront that we don't currently have a way
to develop for the Windows(R) platform, so ongoing maintenance may be
an issue unless someone with Windows expertise steps up to
periodically build the code and keep it "live".

> Are there any particular process requirements in terms of feeding
  back the changes to get them integrated?

Just file a Trac ticket with your patch and we'll take it forward from
there.

>  A preferred diff command?

Any readable format will do, e.g., `diff -u`.

> My motivation here is to get a completely clean compile with no warnings.

Cool.

Some questions:

1) What build environment are you using?  Is it open-source?

2) How are you handling make rules---our makefiles are dependent on
   <sys.mk> doing the right thing.

3) libelf uses mmap() internally; how much of a portability hurdle is
   this?

4) Finally, are you attempting to port the test suites too?  If so,
   any issues there?


[...snip...]

> Another choice is to explicitly cast size --> size_t knowing that
  the realloc() is always going to be < 32bits in size.

In this case a (size_t) cast should be good enough---it would be a
no-op on 64 bit systems, and 32 bit POSIX-like systems aren't going to
be able to deal with memory arenas larger than process address space
anyway.

-- Koshy

Re: [Elftoolchain-developers] windows porting...

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

> I've got a need to port elftoolchain to Windows, and am in the
  process of doing so.

Best of luck!  Our current porting targets are open-source POSIX
systems. To the best of our knowledge, you would be the first person
attempting a Windows(R) port.

Changes that improve our code's portability would be welcome.

Its also fair to point out upfront that we don't currently have a way
to develop for the Windows(R) platform, so ongoing maintenance may be
an issue unless someone with Windows expertise steps up to
periodically build the code and keep it "live".

> Are there any particular process requirements in terms of feeding
  back the changes to get them integrated?

Just file a Trac ticket with your patch and we'll take it forward from
there.

>  A preferred diff command?

Any readable format will do, e.g., `diff -u`.

> My motivation here is to get a completely clean compile with no warnings.

Cool.

Some questions:

1) What build environment are you using?  Is it open-source?

2) How are you handling make rules---our makefiles are dependent on
   <sys.mk> doing the right thing.

3) libelf uses mmap() internally; how much of a portability hurdle is
   this?

4) Finally, are you attempting to port the test suites too?  If so,
   any issues there?


[...snip...]

> Another choice is to explicitly cast size --> size_t knowing that
  the realloc() is always going to be < 32bits in size.

In this case a (size_t) cast should be good enough---it would be a
no-op on 64 bit systems, and 32 bit POSIX-like systems aren't going to
be able to deal with memory arenas larger than process address space
anyway.

-- Koshy

Re: [Elftoolchain-developers] windows porting...

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

On Wed, Oct 06, 2010 at 01:44:46PM -0500, Gorton, Richard wrote:
> 
> Hi,
> 
> I've got a need to port elftoolchain to Windows, and am in the process of doing so.  Are there any particular process requirements in terms of feeding back the changes to get them integrated?  A preferred diff command?

Sounds cool! Feedbacks are always appreciated :) Just curious, are you
porting it to cygwin or native Windows?

> My motivation here is to get a completely clean compile with no warnings.

That's always our goal: clean code.

[snip]

> Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size.

I agree with this apporach. realloc()/malloc() in libdwarf should be
always < 32bits in size.  I committed a fix in r1211. It'd be great if
you can verify the warnings are gone.

Thanks,
Kai

[Elftoolchain-developers] windows porting...

[Gorton, R. <Ric...@am...>]

Hi,

I've got a need to port elftoolchain to Windows, and am in the process of doing so.  Are there any particular process requirements in terms of feeding back the changes to get them integrated?  A preferred diff command?
My motivation here is to get a completely clean compile with no warnings.

Some changes are small, at least one requires a deeper understanding of the intent of a fair amount of the implementation code - realloc(<address>, uint64_t) on a 32-bit os.  An example is _dwarf_write_lsb_alloc()
	...
	*block = realloc (*block, *size); where size is a parameter == uint64_t *size.

On a 32-bit OS, size_t is uint32_t; the compiler legitimately warns about possible loss of data.
In most cases, I suspect that a realloc() is not expected to be > 32bits in size, so the warning can mostly be ignored.

One (moderately clean) way to detect/prevent the actual loss is to write a little jacket function:
void *myrealloc (void ptr, uint64_t size) {
    size_t mysize = (size_t) size;
    if (size) != mysize) {
	DWARF_SET_ERROR(<stuff>);
	return NULL;
    } else {
      return realloc(ptr, mysize);
    }
}

And then have two different myrealloc functions, depending on the OS.
Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size.


Richard Gorton
GPU Developer Tools

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

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

> But the ELF file given as an argument to my program is not modified.
> In other words, the ELF file should have been modified after my program adds
> a new section into the ELF file.

Thank you for the sample test program.

The behaviour is very probably a bug in libelf: ELF_C_RDWR handling is
currently broken, see:
http://sourceforge.net/apps/trac/elftoolchain/ticket/269.

I'm working on a fix.

Koshy