elftoolchain-developers — Discussion on elftoolchain development.

Re: [Elftoolchain-developers] filename conflicts with RedHat/mr511.de libelf

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

> One of the problems I have with packaging libelf for Debian is that the
> installed files would conflict with those in the libelfg0[-dev] and the
> libelf[1|-dev] packages already in Debian.  These are built from libelf
> (from mr511.de) and elfutils (from RedHat) respectively.

> 1. I will have to change the 'source' package names to not conflict with
> these (I choose libbsdelf: http://bugs.debian.org/473188 but that can be
> changed if we wish to, so suggestions are welcome).  If libelf and the
> rest of the ELF toolchain will always be distributed as a single unit, I
> can use elftoolchain as the source package name.

> 2. To handle the conflict of files, we could declare a "Conflict" of
> installation of these packages with those that we build.  However this
> means that software that is linked to these existing packages cannot
> co-exist with our installed libraries.  This includes the following:

> elfutils - collection of utilities to handle ELF objects
> bug-buddy- GNOME Desktop Environment bug reporting tool
> ltrace - Tracks runtime library calls in dynamically linked programs
> prelink - ELF prelinking utility to speed up dynamic linking
> scsh-0.6 - A `scheme' interpreter designed for writing system programs
> mpatrol(c2) - A library for debugging memory allocations
> 
> libelf1 and libelfg0 (the shared library packages) are able to coexist
> right now because they ship /usr/lib/libelf.so.1 and
> /usr/lib/libelf.so.0 but they are certain to conflict when libelfg0 gets
> a SONAME bump.
> 
> libelf-dev and libelfg0-dev already declare a Conflict on each other and
> there is no way out (they install files with conflicting names in the
> same area).
> 
> So this business is messy.  Koshy, is it OK if I continue with this and
> declare "Conflict" between the packages?  How do FreeBSD and NetBSD
> handle this?

One suggestion could be to name the installed library "libbsdelf"
on Linux.  The <libelf.h> and <gelf.h> headers could then be installed
in a non-conflicting location [/usr/include/bsd/ (say) or whereever
other headers of BSD lineage reside].  The synopsis in the elf.3
manual page would also need to be updated to reflect the new
locations.

Our tools could get installed with a "bsd" prefix (e.g., bsdar, bsdnm,
etc.) and all should hopefully be well.

NetBSD pkgsrc would have similar conflicts as Debian/GNU Linux till
the time libelf enters the base system.

On FreeBSD the GNU library installs under $LOCALBASE (i.e.,
/usr/local/), while the native library goes into /usr/lib/.  The
headers end up in $LOCALBASE/include [gnu libelf] and /usr/include/
[native], so there is no conflict.

Koshy

[Elftoolchain-developers] filename conflicts with RedHat/mr511.de libelf

[Y G. A. N. <gir...@ap...>]

Hi,

One of the problems I have with packaging libelf for Debian is that the
installed files would conflict with those in the libelfg0[-dev] and the
libelf[1|-dev] packages already in Debian.  These are built from libelf
(from mr511.de) and elfutils (from RedHat) respectively.

1. I will have to change the 'source' package names to not conflict with
these (I choose libbsdelf: http://bugs.debian.org/473188 but that can be
changed if we wish to, so suggestions are welcome).  If libelf and the
rest of the ELF toolchain will always be distributed as a single unit, I
can use elftoolchain as the source package name.

2. To handle the conflict of files, we could declare a "Conflict" of
installation of these packages with those that we build.  However this
means that software that is linked to these existing packages cannot
co-exist with our installed libraries.  This includes the following:

elfutils - collection of utilities to handle ELF objects
bug-buddy- GNOME Desktop Environment bug reporting tool
ltrace - Tracks runtime library calls in dynamically linked programs
prelink - ELF prelinking utility to speed up dynamic linking
scsh-0.6 - A `scheme' interpreter designed for writing system programs
mpatrol(c2) - A library for debugging memory allocations

libelf1 and libelfg0 (the shared library packages) are able to coexist
right now because they ship /usr/lib/libelf.so.1 and
/usr/lib/libelf.so.0 but they are certain to conflict when libelfg0 gets
a SONAME bump.

libelf-dev and libelfg0-dev already declare a Conflict on each other and
there is no way out (they install files with conflicting names in the
same area).

So this business is messy.  Koshy, is it OK if I continue with this and
declare "Conflict" between the packages?  How do FreeBSD and NetBSD
handle this?

Cheers,

Giridhar

-- 
Y Giridhar Appaji Nag | http://appaji.net/

Re: [Elftoolchain-developers] [resend] experiment of porting libelf to Debian

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

On Tue, Aug 05, 2008 at 08:02:31AM -0000, Joseph Koshy wrote:
> 
> [Resending]
> 
> kaiw> b) GNU and BSD tsort are probably incompatibible, you can see some
> kaiw> tsort warnings during compiling, but I don't know if that affects
> kaiw> the resulting files.
> 
> The warning turns out to be caused by the following:
> 
> - In "elf_memory.o", elf_memory() uses _libelf_ar_open() to open ar(1)
>   archives.
> - However, in "libelf_ar.o", the _libelf_ar_open_member() function
>   in turn uses elf_memory() on archive members inside an archive.
> 
> >From the point of view of tsort(1) these two objects have a cyclic
> dependency.  Bug #2038553 has been logged.

I guess this is not a problem?

Also, excerpt from the manual page of BSD tsort(1):

     -q      Do not display informational messages about cycles.  This is pri-
             marily intended for building libraries, where optimal ordering is
             not critical, and cycles occur often.

and freebsd make(1) always invoke tsort with -q:

% cd /usr/share/mk
% grep tsort *

bsd.lib.mk:     @${AR} cq ${.TARGET} `lorder ${OBJS} ${STATICOBJS} | tsort -q` ${ARADD}
bsd.lib.mk:     @${AR} cq ${.TARGET} `NM='${NM}' lorder ${OBJS} ${STATICOBJS} | tsort -q` ${ARADD}
bsd.lib.mk:     @${AR} cq ${.TARGET} `lorder ${POBJS} | tsort -q` ${ARADD}
bsd.lib.mk:     @${AR} cq ${.TARGET} `NM='${NM}' lorder ${POBJS} | tsort -q` ${ARADD}
bsd.lib.mk:         `lorder ${SOBJS} | tsort -q` ${LDADD}
bsd.lib.mk:         `NM='${NM}' lorder ${SOBJS} | tsort -q` ${LDADD}

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

On Fri, Aug 01, 2008 at 02:06:42PM +0530, Y Giridhar Appaji Nag wrote:
> Hi Kai,
> 
> On 08/07/31 18:41 +0200, Kai Wang said ...
> > I've been trying to port libelf to Debian today, and I managed
> > make it basically working. There are some issues unclear to me:
> 
> I did this a few weeks ago and sent a patch to Koshy, unfortunately this
> mailing list wasn't set up then.
> 
> > 2. strlcat/strlcpy
> > 
> > 3. STAILQ
> 
> For Debian, these definitions are provided in the libbsd package.  For
> other Linuxes, we would have to define these.
> 
> > 4. pmake compatibility
> 
> The pmake in Debian is very old, for Debian packages, I was intending to
> use the make from the freebsd5-buildutils package.

I just tried this package, the header files can be correctly installed
with freebsd-make.

Thanks,
Kai

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

Sorry about the late reply, my $job is pushing me recently...

On Sat, Aug 02, 2008 at 02:47:22PM -0000, Joseph Koshy wrote:
> The strl*() APIs are cleaner, but I'm wondering if we should just bite
> the bullet and stick to the portable APIs.
> 
> For example:
> 
> Index: elf_errmsg.c
> ===================================================================
> --- elf_errmsg.c	(revision 209)
> +++ elf_errmsg.c	(working copy)
> @@ -27,6 +27,7 @@
>  #include <sys/cdefs.h>
>  
>  #include <libelf.h>
> +#include <stdio.h>
>  #include <string.h>
>  
>  #include "_libelf.h"
> @@ -74,11 +75,9 @@
>  	if (error < 0 || error >= ELF_E_NUM)
>  		return _libelf_errors[ELF_E_NUM];
>  	if (oserr) {
> -		strlcpy(LIBELF_PRIVATE(msg), _libelf_errors[error],
> -		    sizeof(LIBELF_PRIVATE(msg)));
> -		strlcat(LIBELF_PRIVATE(msg), ": ", sizeof(LIBELF_PRIVATE(msg)));
> -		strlcat(LIBELF_PRIVATE(msg), strerror(oserr),
> -		    sizeof(LIBELF_PRIVATE(msg)));
> +		(void) snprintf(LIBELF_PRIVATE(msg),
> +		    sizeof(LIBELF_PRIVATE(msg)), "%s: %s",
> +		    _libelf_errors[error], strerror(oserr));
>  		return (const char *)&LIBELF_PRIVATE(msg);
>  	}
>  	return _libelf_errors[error];
> 
> 
> Comments?

This looks great! I wasn't thinking of "snprintf"...

I just tried compiling libelf r217 on Debian and I think the
patches you committed today work well.

Thanks,
Kai

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

> >   % pmake -V unix
> >   We run NetBSD.
> > 
> >   % freebsd-make -V unix
> >   We run FreeBSD, not UNIX.
> 
> I filed these as #493839 (pmake) and #493841 (freebsd5-buildutils) in Debian.
> Do we intend to use the output of these in building libelf?

Yes, we use the contents of the 'unix' make(1) variable to determine
the *target* OS in a cross-build that libelf is being built for.

More info in README.build.

Koshy

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

[Y G. A. N. <gir...@ap...>]

On 08/08/05 04:52 -0000, Joseph Koshy said ...
>   % pmake -V unix
>   We run NetBSD.
> 
>   % freebsd-make -V unix
>   We run FreeBSD, not UNIX.

I filed these as #493839 (pmake) and #493841 (freebsd5-buildutils) in Debian.
Do we intend to use the output of these in building libelf?

Giridhar

-- 
Y Giridhar Appaji Nag | http://appaji.net/

[Elftoolchain-developers] [resend] experiment of porting libelf to Debian

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

[Resending]

kaiw> b) GNU and BSD tsort are probably incompatibible, you can see some
kaiw> tsort warnings during compiling, but I don't know if that affects
kaiw> the resulting files.

The warning turns out to be caused by the following:

- In "elf_memory.o", elf_memory() uses _libelf_ar_open() to open ar(1)
  archives.
- However, in "libelf_ar.o", the _libelf_ar_open_member() function
  in turn uses elf_memory() on archive members inside an archive.

>From the point of view of tsort(1) these two objects have a cyclic
dependency.  Bug #2038553 has been logged.

Koshy

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

> 4. pmake compatibility

So I took a look at pmake-1.111 in Ubuntu 8.04.1.  For one, the 'unix'
variable is set incorrectly:

  % pmake -V unix
  We run NetBSD.

This should be changed to "We run GNU/Linux." in the installed
"/usr/share/mk/sys.mk".

There's a similar bug for the FreeBSD make package:

  % freebsd-make -V unix
  We run FreeBSD, not UNIX.

Koshy

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

[Y G. A. N. <gir...@ap...>]

On 08/08/02 14:47 -0000, Joseph Koshy said ...
> kaiw> 3. STAILQ Should we just add missing STAILQ defines like we did
> kaiw> for NetBSD?
> 
> Question 1: Is there a package that provides <sys/queue.h> for
> GNU/Linux?

None as far I know.  Debian though has libbsd that provides this as
<bsd/queue.h>

> Question 2: is there a way to distinguish between Debian GNU/Linux and
> the other distributions at compile time?  E.g., is a __Debian__ or
> other pre-processor symbol defined at compile time?

No.

Regards,

Giridhar

-- 
Y Giridhar Appaji Nag | http://appaji.net/

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

> I've been trying to port libelf to Debian today, and I managed
> make it basically working. There are some issues unclear to me:

Thanks.  Giridhar (yganag@) had sent in a patch for a prior revision
of libelf, enabling compilation for GNU/Linux, GNU/Hurd, and
GNU/kFreeBSD.

I'll take a stab at merging the information in both patches.

kaiw> I found that there are two versions of ELF header files which
kaiw> contain ELF structures and other definitions. One is provided by
kaiw> GNU libc, the other one is linux/elf.h(includes asm/elf.h, etc,
kaiw> provided by kernel? ).  I noticed that the one provided by GNU
kaiw> libc has more definitions thus maybe better for us to use. But
kaiw> asm/elf.h provides arch-dependent defines.

kaiw> So, in the patch I included asm/elf.h in _libelf_config.h to get
kaiw> arch-dependent defines (ELF_CLASS, ELF_ARCH, ELF_DATA), and
kaiw> included elf.h(GNU libc) in libelf.h.

This seems ok.

kaiw> 2. strlcat/strlcpy

kaiw> These two functions are very convenient but unfortunately not inside
kaiw> GNU libc. I guess there are two solutions for this:

kaiw> a) Use portable strncpy/strncat, as a result, the code will become
kaiw>    less elegant.
kaiw> b) define strlcpy/strlcat.

kaiw> In the patch I chose b), I added a file called libelf_util.c which
kaiw> defines these two function. (stolen from FreeBSD libc)

yganag> For Debian, these definitions are provided in the libbsd
yganag> package.  For other Linuxes, we would have to define these.

The strl*() APIs are cleaner, but I'm wondering if we should just bite
the bullet and stick to the portable APIs.

For example:

Index: elf_errmsg.c
===================================================================
--- elf_errmsg.c	(revision 209)
+++ elf_errmsg.c	(working copy)
@@ -27,6 +27,7 @@
 #include <sys/cdefs.h>
 
 #include <libelf.h>
+#include <stdio.h>
 #include <string.h>
 
 #include "_libelf.h"
@@ -74,11 +75,9 @@
 	if (error < 0 || error >= ELF_E_NUM)
 		return _libelf_errors[ELF_E_NUM];
 	if (oserr) {
-		strlcpy(LIBELF_PRIVATE(msg), _libelf_errors[error],
-		    sizeof(LIBELF_PRIVATE(msg)));
-		strlcat(LIBELF_PRIVATE(msg), ": ", sizeof(LIBELF_PRIVATE(msg)));
-		strlcat(LIBELF_PRIVATE(msg), strerror(oserr),
-		    sizeof(LIBELF_PRIVATE(msg)));
+		(void) snprintf(LIBELF_PRIVATE(msg),
+		    sizeof(LIBELF_PRIVATE(msg)), "%s: %s",
+		    _libelf_errors[error], strerror(oserr));
 		return (const char *)&LIBELF_PRIVATE(msg);
 	}
 	return _libelf_errors[error];


Comments?

kaiw> 3. STAILQ Should we just add missing STAILQ defines like we did
kaiw> for NetBSD?

Question 1: Is there a package that provides <sys/queue.h> for
GNU/Linux?

Question 2: is there a way to distinguish between Debian GNU/Linux and
the other distributions at compile time?  E.g., is a __Debian__ or
other pre-processor symbol defined at compile time?

kaiw> 4. pmake compatibility

kaiw> a) Seems that header files (gelf.h, libelf.h) can not be
kaiw> installed.  After I typed "pmake install", libraries and manual
kaiw> pages got installed, but not header files.

If there's a port of NetBSD `bmake', could you try that instead of
pmake?

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

kaiw> b) GNU and BSD tsort are probably incompatibible, you can see some
kaiw> tsort warnings during compiling, but I don't know if that affects the
kaiw> resulting files.

What are these warnings?  Our Makefiles don't invoke tsort directly
so if there are warnings we would need to look at the packaged
<bsd.lib.mk>.

Koshy

Re: [Elftoolchain-developers] [patch] experiment of porting libelf to Debian

[Y G. A. N. <gir...@ap...>]

Hi Kai,

On 08/07/31 18:41 +0200, Kai Wang said ...
> I've been trying to port libelf to Debian today, and I managed
> make it basically working. There are some issues unclear to me:

I did this a few weeks ago and sent a patch to Koshy, unfortunately this
mailing list wasn't set up then.

> 2. strlcat/strlcpy
> 
> 3. STAILQ

For Debian, these definitions are provided in the libbsd package.  For
other Linuxes, we would have to define these.

> 4. pmake compatibility

The pmake in Debian is very old, for Debian packages, I was intending to
use the make from the freebsd5-buildutils package.

Regards,

Giridhar

-- 
Y Giridhar Appaji Nag | http://appaji.net/

[Elftoolchain-developers] [patch] experiment of porting libelf to Debian

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

Hi,

I've been trying to port libelf to Debian today, and I managed
make it basically working. There are some issues unclear to me:

(I attached a patch below)

1. elf header files

I found that there are two versions of ELF header files which contain
ELF structures and other definitions. One is provided by GNU libc,
the other one is linux/elf.h(includes asm/elf.h, etc, provided by kernel? ).
I noticed that the one provided by GNU libc has more definitions thus
maybe better for us to use. But asm/elf.h provides arch-dependent defines.

So, in the patch I included asm/elf.h in _libelf_config.h to get
arch-dependent defines (ELF_CLASS, ELF_ARCH, ELF_DATA), and included
elf.h(GNU libc) in libelf.h.

2. strlcat/strlcpy

These two functions are very convenient but unfortunately not inside
GNU libc. I guess there are two solutions for this:

a) Use portable strncpy/strncat, as a result, the code will become
   less elegant.
b) define strlcpy/strlcat.

In the patch I chose b), I added a file called libelf_util.c which
defines these two function. (stolen from FreeBSD libc)

3. STAILQ

Should we just add missing STAILQ defines like we did for NetBSD?

4. pmake compatibility

a) Seems that header files (gelf.h, libelf.h) can not be installed.
After I typed "pmake install", libraries and manual pages got installed,
but not header files.

b) GNU and BSD tsort are probably incompatibible, you can see some
tsort warnings during compiling, but I don't know if that affects the
resulting files.



The patch:

diff -urN elftoolchain/projects/libelf/trunk/_libelf_config.h libelf/_libelf_config.h
--- elftoolchain/projects/libelf/trunk/_libelf_config.h	2008-07-31 12:53:48.000000000 +0200
+++ libelf/_libelf_config.h	2008-07-31 17:37:44.000000000 +0200
@@ -135,6 +135,92 @@
 
 #endif	/* __NetBSD__ */
 
+#ifdef __linux__
+
+#include <asm/elf.h>
+
+#define	LIBELF_CONFIG_ADDR	1
+#define	LIBELF_CONFIG_BYTE	1
+#define	LIBELF_CONFIG_DYN	1
+#define	LIBELF_CONFIG_EHDR	1
+#define	LIBELF_CONFIG_HALF	1
+#define	LIBELF_CONFIG_NOTE	1
+#define	LIBELF_CONFIG_OFF	1
+#define	LIBELF_CONFIG_PHDR	1
+#define	LIBELF_CONFIG_REL	1
+#define	LIBELF_CONFIG_RELA	1
+#define	LIBELF_CONFIG_SHDR	1
+#define	LIBELF_CONFIG_SWORD	1
+#define	LIBELF_CONFIG_SYM	1
+#define	LIBELF_CONFIG_WORD	1
+
+#define	LIBELF_CONFIG_SXWORD	1
+#define	LIBELF_CONFIG_XWORD	1
+
+#define	LIBELF_CONFIG_MOVEP	1
+
+#define	LIBELF_CONFIG_VDEF	1
+#define	LIBELF_CONFIG_VNEED	1
+
+#define	LIBELF_VCSID(ID)
+
+#ifndef	STAILQ_EMPTY
+#define STAILQ_EMPTY(head)      ((head)->stqh_first == NULL)
+#endif
+
+#ifndef	STAILQ_FIRST
+#define STAILQ_FIRST(head)      ((head)->stqh_first)
+#endif
+
+#ifndef	STAILQ_FOREACH
+#define STAILQ_FOREACH(var, head, field)                                \
+        for((var) = STAILQ_FIRST((head));                               \
+           (var);                                                       \
+           (var) = STAILQ_NEXT((var), field))
+#endif
+
+#ifndef	SLIST_FOREACH_SAFE
+#define STAILQ_FOREACH_SAFE(var, head, field, tvar)            \
+       for ((var) = STAILQ_FIRST((head));                      \
+            (var) && ((tvar) = STAILQ_NEXT((var), field), 1);  \
+            (var) = (tvar))
+#endif
+
+#ifndef	STAILQ_INIT
+#define STAILQ_INIT(head) do {                                          \
+        STAILQ_FIRST((head)) = NULL;                                    \
+        (head)->stqh_last = &STAILQ_FIRST((head));                      \
+} while (0)
+#endif
+
+#ifndef	STAILQ_INSERT_TAIL
+#define STAILQ_INSERT_TAIL(head, elm, field) do {                       \
+        STAILQ_NEXT((elm), field) = NULL;                               \
+        *(head)->stqh_last = (elm);                                     \
+        (head)->stqh_last = &STAILQ_NEXT((elm), field);                 \
+} while (0)
+#endif
+
+#ifndef	STAILQ_LAST
+#define STAILQ_LAST(head, type, field)                                  \
+        (STAILQ_EMPTY((head)) ?                                         \
+                NULL :                                                  \
+                ((struct type *)(void *)                                \
+                ((char *)((head)->stqh_last) - offsetof(struct type, field))))
+#endif
+
+#define	LIBELF_ARCH		ELF_ARCH
+#define	LIBELF_BYTEORDER	ELF_DATA
+#define	LIBELF_CLASS		ELF_CLASS
+
+#if	ELF_CLASS == ELFCLASS32
+#define	Elf_Note		Elf32_Nhdr
+#else
+#define	Elf_Note		Elf64_Nhdr
+#endif
+
+#endif	/* __linux__ */
+
 /*
  * Symbols that are sometimes missing in system headers.
  */
diff -urN elftoolchain/projects/libelf/trunk/libelf.h libelf/libelf.h
--- elftoolchain/projects/libelf/trunk/libelf.h	2008-07-31 12:53:48.000000000 +0200
+++ libelf/libelf.h	2008-07-31 17:34:29.000000000 +0200
@@ -38,6 +38,8 @@
 #elif defined(__NetBSD__)
 #include <sys/exec_elf.h>
 #elif defined(__linux__)
+#include <elf.h>
+#include <stdint.h>
 #endif
 
 /* Library private data structures */
diff -urN elftoolchain/projects/libelf/trunk/libelf_util.c libelf/libelf_util.c
--- elftoolchain/projects/libelf/trunk/libelf_util.c	1970-01-01 01:00:00.000000000 +0100
+++ libelf/libelf_util.c	2008-07-31 17:14:37.000000000 +0200
@@ -0,0 +1,65 @@
+#ifdef	__linux__
+
+#include <string.h>
+
+size_t
+strlcat(dst, src, siz)
+        char *dst;
+        const char *src;
+        size_t siz;
+{
+        char *d = dst;
+        const char *s = src;
+        size_t n = siz;
+        size_t dlen;
+
+        /* Find the end of dst and adjust bytes left but don't go past end */
+        while (n-- != 0 && *d != '\0')
+                d++;
+        dlen = d - dst;
+        n = siz - dlen;
+
+        if (n == 0)
+                return(dlen + strlen(s));
+        while (*s != '\0') {
+                if (n != 1) {
+                        *d++ = *s;
+                        n--;
+                }
+                s++;
+        }
+        *d = '\0';
+
+        return(dlen + (s - src));       /* count does not include NUL */
+}
+
+size_t
+strlcpy(dst, src, siz)
+        char *dst;
+        const char *src;
+        size_t siz;
+{
+        char *d = dst;
+        const char *s = src;
+        size_t n = siz;
+
+        /* Copy as many bytes as will fit */
+        if (n != 0 && --n != 0) {
+                do {
+                        if ((*d++ = *s++) == 0)
+                                break;
+                } while (--n != 0);
+        }
+
+        /* Not enough room in dst, add NUL and traverse rest of src */
+        if (n == 0) {
+                if (siz != 0)
+                        *d = '\0';              /* NUL-terminate dst */
+                while (*s++)
+                        ;
+        }
+
+        return(s - src - 1);    /* count does not include NUL */
+}
+
+#endif
diff -urN elftoolchain/projects/libelf/trunk/Makefile libelf/Makefile
--- elftoolchain/projects/libelf/trunk/Makefile	2008-07-31 12:53:48.000000000 +0200
+++ libelf/Makefile	2008-07-31 17:14:57.000000000 +0200
@@ -50,6 +50,7 @@
 	libelf_extended.c					\
 	libelf_phdr.c						\
 	libelf_shdr.c						\
+	libelf_util.c						\
 	libelf_xlate.c						\
 	${GENSRCS}
 INCS=	libelf.h gelf.h

[Elftoolchain-developers] brandelf(1) patch using libelf.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

I wrote patch for brandelf(1) to use libelf.

Would you review this patch? patch against usr.bin/brandelf in 7-STABLE.

You can get this patch also in 
http://home.megapass.net/~supr07/brandelf.patch

Best Regards,
Hyogeol Lee

diff -urN usr.bin/brandelf.org/Makefile usr.bin/brandelf/Makefile
- --- usr.bin/brandelf.org/Makefile    2003-06-15 04:32:51.000000000 +0900
+++ usr.bin/brandelf/Makefile    2008-07-29 19:44:24.000000000 +0900
@@ -1,5 +1,6 @@
~ # $FreeBSD: src/usr.bin/brandelf/Makefile,v 1.7 2003/06/14 19:32:51 
obrien Exp $

~ PROG=    brandelf
+LDADD=    -lelf

~ .include <bsd.prog.mk>
diff -urN usr.bin/brandelf.org/brandelf.c usr.bin/brandelf/brandelf.c
- --- usr.bin/brandelf.org/brandelf.c    2005-05-21 18:55:04.000000000 +0900
+++ usr.bin/brandelf/brandelf.c    2008-07-29 21:09:38.000000000 +0900
@@ -1,4 +1,5 @@
~ /*-
+ * Copyright (c) 2008 Hyogeol Lee
~  * Copyright (c) 2000, 2001 David O'Brien
~  * Copyright (c) 1996 S�ren Schmidt
~  * All rights reserved.
@@ -31,10 +32,12 @@
~ __FBSDID("$FreeBSD: src/usr.bin/brandelf/brandelf.c,v 1.25 2005/05/21 
09:55:04 ru Exp $");

~ #include <sys/types.h>
- -#include <sys/elf_common.h>
+#include <sys/stat.h>
~ #include <sys/errno.h>
~ #include <err.h>
~ #include <fcntl.h>
+#include <gelf.h>
+#include <libelf.h>
~ #include <stdio.h>
~ #include <stdlib.h>
~ #include <string.h>
@@ -42,6 +45,8 @@

~ static int elftype(const char *);
~ static const char *iselftype(int);
+static int isfile(const char *);
+static Elf *openelf(int, const char *);
~ static void printelftypes(void);
~ static void usage(void);

@@ -51,20 +56,26 @@
~ };
~ /* XXX - any more types? */
~ static struct ELFtypes elftypes[] = {
- -    { "FreeBSD",    ELFOSABI_FREEBSD },
+    { "NetBSD",    ELFOSABI_NETBSD},
~     { "Linux",    ELFOSABI_LINUX },
~     { "Solaris",    ELFOSABI_SOLARIS },
+    { "FreeBSD",    ELFOSABI_FREEBSD },
+    { "OpenBSD",    ELFOSABI_OPENBSD },
~     { "SVR4",    ELFOSABI_SYSV }
~ };

~ int
~ main(int argc, char **argv)
~ {
- -
+    GElf_Ehdr ehdr;
+    Elf *elf;
~     const char *strtype = "FreeBSD";
~     int type = ELFOSABI_FREEBSD;
~     int retval = 0;
- -    int ch, change = 0, verbose = 0, force = 0, listed = 0;
+    int ch, change = 0, verbose = 0, force = 0, listed = 0, e_err = 0;
+
+    if (elf_version(EV_CURRENT) == EV_NONE)
+        errx(1, "elf_version error");

~     while ((ch = getopt(argc, argv, "f:lt:v")) != -1)
~         switch (ch) {
@@ -114,29 +125,36 @@

~     while (argc) {
~         int fd;
- -        char buffer[EI_NIDENT];

- -        if ((fd = open(argv[0], change || force ? O_RDWR : O_RDONLY, 
0)) < 0) {
+        if (isfile(argv[0]) != 0) {
+            retval = 1;
+            goto fail2;
+        }
+        if ((fd = open(argv[0], change || force ?
+                O_RDWR : O_RDONLY, 0)) < 0) {
~             warn("error opening file %s", argv[0]);
~             retval = 1;
~             goto fail;
~         }
- -        if (read(fd, buffer, EI_NIDENT) < EI_NIDENT) {
- -            warnx("file '%s' too short", argv[0]);
+        if ((elf = openelf(fd, argv[0])) == NULL) {
~             retval = 1;
~             goto fail;
~         }
- -        if (buffer[0] != ELFMAG0 || buffer[1] != ELFMAG1 ||
- -            buffer[2] != ELFMAG2 || buffer[3] != ELFMAG3) {
- -            warnx("file '%s' is not ELF format", argv[0]);
+        if (gelf_getehdr(elf, &ehdr) == NULL) {
+            if ((e_err = elf_errno()) != 0)
+                warnx("gelf_getehdr : %s",
+                    elf_errmsg(e_err));
+            else
+                warnx("gelf_getehdr error");
~             retval = 1;
~             goto fail;
~         }
~         if (!change && !force) {
~             fprintf(stdout,
- -                "File '%s' is of brand '%s' (%u).\n",
- -                argv[0], iselftype(buffer[EI_OSABI]),
- -                buffer[EI_OSABI]);
+                "File '%s' is of brand '%s' (%u).\n",
+                argv[0], iselftype(ehdr.e_ident[EI_OSABI]),
+                ehdr.e_ident[EI_OSABI]);
+
~             if (!iselftype(type)) {
~                 warnx("ELF ABI Brand '%u' is unknown",
~                       type);
@@ -144,21 +162,39 @@
~             }
~         }
~         else {
- -            buffer[EI_OSABI] = type;
- -            lseek(fd, 0, SEEK_SET);
- -            if (write(fd, buffer, EI_NIDENT) != EI_NIDENT) {
- -                warn("error writing %s %d", argv[0], fd);
+            ehdr.e_ident[EI_OSABI] = type;
+            if (gelf_update_ehdr(elf, &ehdr) == 0) {
+                if ((e_err = elf_errno()) != 0)
+                    warnx("gelf_update_ehdr error : %s",
+                        elf_errmsg(e_err));
+                else
+                    warnx("gelf_update_ehdr error");
+                retval = 1;
+                goto fail;
+            }
+
+            if (elf_update(elf, ELF_C_WRITE) == -1) {
+                if ((e_err = elf_errno()) != 0)
+                    warnx("elf_update error : %s",
+                        elf_errmsg(e_err));
+                else
+                    warnx("elf_update error");
~                 retval = 1;
~                 goto fail;
~             }
~         }
~ fail:
- -        close(fd);
+        elf_end(elf);
+        if (close(fd) == -1) {
+            warnx("%s: close error", argv[0]);
+            retval = 1;
+        }
+fail2:
~         argc--;
~         argv++;
~     }

- -    return retval;
+    return (retval);
~ }

~ static void
@@ -178,8 +214,36 @@
~          elfwalk < sizeof(elftypes)/sizeof(elftypes[0]);
~          elfwalk++)
~         if (etype == elftypes[elfwalk].value)
- -            return elftypes[elfwalk].str;
- -    return 0;
+            return (elftypes[elfwalk].str);
+    return (0);
+}
+
+/* Return 0 if path is regular file. */
+static int
+isfile(const char *path)
+{
+    struct stat sb;
+
+    if (path == NULL)
+        return (1);
+
+    errno = 0;
+    if (stat(path, &sb) != 0) {
+        if (errno == ENOENT)
+            warnx("'%s': No such file", path);
+        else
+            warn("'%s'", path);
+
+        return (1);
+    }
+
+    if (!S_ISLNK(sb.st_mode) && !S_ISREG(sb.st_mode)) {
+        warnx("Warning: '%s' is not an ordinary file", path);
+
+        return (1);
+    }
+
+    return (0);
~ }

~ static int
@@ -191,8 +255,51 @@
~          elfwalk < sizeof(elftypes)/sizeof(elftypes[0]);
~          elfwalk++)
~         if (strcasecmp(elfstrtype, elftypes[elfwalk].str) == 0)
- -            return elftypes[elfwalk].value;
- -    return -1;
+            return (elftypes[elfwalk].value);
+    return (-1);
+}
+
+static Elf *
+openelf(int fd, const char *name)
+{
+    Elf *elf;
+    Elf_Cmd cmd;
+    Elf_Kind kind;
+    int e_err = 0;
+
+    if (fd < 0)
+        return (NULL);
+
+    /* Archive does not support write mode. So try ar type by read cmd. */
+    cmd = ELF_C_READ;
+begin:
+    if ((elf = elf_begin(fd, cmd, (Elf *) NULL)) == NULL) {
+        if ((e_err = elf_errno()) != 0)
+            warnx("elf_begin error : %s",
+                elf_errmsg(e_err));
+        else
+            warnx("elf_begin error");
+
+        return (NULL);
+    }
+
+    if ((kind = elf_kind(elf)) != ELF_K_ELF) {
+        if (kind == ELF_K_AR)
+            warnx("file '%s' is an archive.", name);
+        else
+            warnx("file '%s' is not ELF format", name);
+
+        return (NULL);
+    }
+
+    if (cmd == ELF_C_RDWR)
+        return (elf);
+
+    elf_end(elf);
+
+    cmd = ELF_C_RDWR;
+
+    goto begin;
~ }

~ static void
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkiPDJMACgkQ1D7/GiH6QSFdHwCfazW6XekCAaXryWLXuw0Q74qx
GuAAn3IKCb31THR2zH80tQbZ1PPVZHqQ
=jEJ/
-----END PGP SIGNATURE-----

Re: [Elftoolchain-developers] Short-term roadmap

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

> Yes, 'brandelf'. It may does not take much time to implement/patch
> 'brandelf'.

Agreed.

> It is good idea to prepare 'as', but I'd like to put it later
> release because it will take much time to implement.

Yes.  That's for the next release definitely.

Koshy

Re: [Elftoolchain-developers] Short-term roadmap

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

This is a resend msg, I forgot to CC developer list last time.
Sorry about this.

On Mon, Jul 21, 2008 at 03:32:00AM -0000, Joseph Koshy wrote:
> 
> Hi,
> 
> I would like to open discussion on our short term roadmap: i.e.,
> planning for our first release.  The goal of this release would be
> to produce a tarball that the other projects could start looking
> at.

Great! :-)

> It seems to me that we have the following tasks need to be completed
> before we can have any kind of release:
> 
> 1) Bring libelf to the point where ar(1) can be implemented using
>    it:
>    1.1) libelf needs to be able to create ar(1) archives [Task #149800]
>    1.2) libelf needs to handle BSD format ar(1) archives.  Currently
>         it only understands SysV format archives. [Task #149801]
> 
>    These tasks would be owned by me, unless someone else wants to take
>    them up.

Just in case, I can help at least with 1.2) if need, and of course
I will help with testing.

> 2) Then we would need to retarget ar(1) to use the new libelf instead
>    of libarchive. [Task #149994] (owned by jkoshy or kaiwang27)

I'll take this task.

> 3) Then a sanity-check porting pass to port ar(1) to other OSes.
>  
> `nm', `size' and `strings' run fine on NetBSD and FreeBSD.  I haven't
> looked at `elfcopy' on NetBSD yet but do not anticipate trouble
> either.

elfcopy is not completed yet...

> So the questions are:
> 
> - Do you think we should defer the first release till we have other
>   tools ready?  If so, which tools would these be?

I think we should. elfcopy probably will not be finished at the time of
our first release, if the release is soon. (strip was basically finished though)
So I guess we should exclude elfcopy/strip from first release...

> - If the idea of a release is ok, what OSes do we target for the first
>   release?

NetBSD and FreeBSD? 

By the way, What does it looks like on OpenBSD? Is it easy to port
to Linux?

> Also: do you know of any organization offering a "build farm" with
> different OSes?  I'd love to have a collection of buildbot/bitten
> slaves that could build our source tree on different OSes
> automatically.
> 
> Koshy
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers

Re: [Elftoolchain-developers] Short-term roadmap

[Y G. A. N. <gir...@ap...>]

On 08/07/22 21:16 +0900, Hyogeol Lee said ...
> 
> Joseph Koshy :
> |
> | - If the idea of a release is ok, what OSes do we target for the first
> |   release?
> 
> FreeBSD/NetBSD.

Linux also, please :)

> | Also: do you know of any organization offering a "build farm" with
> | different OSes?  I'd love to have a collection of buildbot/bitten
> | slaves that could build our source tree on different OSes
> | automatically.

I came across openSUSE Build Service a few months ago, but I wasn't able
to sign in properly even once and the service is restricted to Linux.

Cheers,

Giridhar

-- 
Y Giridhar Appaji Nag | http://appaji.net/

Re: [Elftoolchain-developers] Short-term roadmap

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joseph Koshy :
| Hi,
|
| I would like to open discussion on our short term roadmap: i.e.,
| planning for our first release.  The goal of this release would be
| to produce a tarball that the other projects could start looking
| at.
|
| It seems to me that we have the following tasks need to be completed
| before we can have any kind of release:
|
| 1) Bring libelf to the point where ar(1) can be implemented using
|    it:
|    1.1) libelf needs to be able to create ar(1) archives [Task #149800]
|    1.2) libelf needs to handle BSD format ar(1) archives.  Currently
|         it only understands SysV format archives. [Task #149801]
|
|    These tasks would be owned by me, unless someone else wants to take
|    them up.
|
| 2) Then we would need to retarget ar(1) to use the new libelf instead
|    of libarchive. [Task #149994] (owned by jkoshy or kaiwang27)
|
| 3) Then a sanity-check porting pass to port ar(1) to other OSes.
|  
| `nm', `size' and `strings' run fine on NetBSD and FreeBSD.  I haven't
| looked at `elfcopy' on NetBSD yet but do not anticipate trouble
| either.
|
| So the questions are:
|
| - Do you think we should defer the first release till we have other
|   tools ready?  If so, which tools would these be?


Yes, 'brandelf'. It may does not take much time to implement/patch

'brandelf'. It is good idea to prepare 'as', but I'd like to put it 
later release

because it will take much time to implement.


|
| - If the idea of a release is ok, what OSes do we target for the first
|   release?

FreeBSD/NetBSD.
|
| Also: do you know of any organization offering a "build farm" with
| different OSes?  I'd love to have a collection of buildbot/bitten
| slaves that could build our source tree on different OSes
| automatically.
|
| Koshy


Best Regards,
Hyogeol Lee
- ----
hyo...@gm...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkiFz4UACgkQ1D7/GiH6QSEduQCghMxxqEysj15k3ubON1froAsh
VLAAoMPCJkxl/1P0QkNpEr1F8skZdzsz
=XD9o
-----END PGP SIGNATURE-----

[Elftoolchain-developers] Short-term roadmap

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

Hi,

I would like to open discussion on our short term roadmap: i.e.,
planning for our first release.  The goal of this release would be
to produce a tarball that the other projects could start looking
at.

It seems to me that we have the following tasks need to be completed
before we can have any kind of release:

1) Bring libelf to the point where ar(1) can be implemented using
   it:
   1.1) libelf needs to be able to create ar(1) archives [Task #149800]
   1.2) libelf needs to handle BSD format ar(1) archives.  Currently
        it only understands SysV format archives. [Task #149801]

   These tasks would be owned by me, unless someone else wants to take
   them up.

2) Then we would need to retarget ar(1) to use the new libelf instead
   of libarchive. [Task #149994] (owned by jkoshy or kaiwang27)

3) Then a sanity-check porting pass to port ar(1) to other OSes.
 
`nm', `size' and `strings' run fine on NetBSD and FreeBSD.  I haven't
looked at `elfcopy' on NetBSD yet but do not anticipate trouble
either.

So the questions are:

- Do you think we should defer the first release till we have other
  tools ready?  If so, which tools would these be?

- If the idea of a release is ok, what OSes do we target for the first
  release?

Also: do you know of any organization offering a "build farm" with
different OSes?  I'd love to have a collection of buildbot/bitten
slaves that could build our source tree on different OSes
automatically.

Koshy