elftoolchain-developers — Discussion on elftoolchain development.

Re: [Elftoolchain-developers] libelf and linux objtool

[Michael F. <mf...@mf...>]

Thanks for your response.

On 2019-06-09, Joseph Koshy <jk...@us...> wrote:
> On Sun, Jun 09, 2019 at 02:25:38AM -0700, Michael Forney wrote:
> m.f> 3. I also noticed that when elf_update recomputes
> m.f> the section layout, it leaves the section offset
> m.f> of SHT_NOBITS and SHT_NULL sections alone while
> m.f> the others are updated. elfutils sets the offset
> m.f> of the section based on the ending of the previous
> m.f> section. Does this offset have any meaning, or
> m.f> is it just arbitrary? Either way, maybe it makes
> m.f> sense to set it to the end of the previous section
> m.f> to avoid inheriting the value from the original
> m.f> section layout.
>
> Would you have a short example program that shows
> the difference in behavior of elfutils' libelf and
> elftoolchain's libelf?
>
> Per my understanding, for a section of type SHT_NULL,
> the rest of the fields in the section header are
> undefined.  For a section of type SHT_NOBITS,
> the offset and size fields are defined to be a
> 'conceptual' offset and size of the section; these
> values would be set by the application that adds a
> SHT_NOBITS section to the object.
>
> When libelf is told to lay out an ELF object (i.e.,
> when the ELF_F_LAYOUT flag is not set on the Elf
> descriptor), then it isn't clear what the fields of a
> SHT_NOBITS section header would need to be set to.

I might be able to come up with an example later, but hopefully the
attached shell session explains the difference I'm seeing.

> m.f> 4. This is a bit unrelated to objtool,
> m.f> but I noticed that elfdefinitions.h contains
> m.f> several enums with values that are too big for
> m.f> int (specifically, EF_PPC_EMB, SHF_COMDEF,
> m.f> SHF_MIPS_STRING, SHF_EXCLUDE, SHF_MASKPROC,
> m.f> SHT_LOUSER, and SHT_HIUSER). The C standard says
> m.f> that all enumerator values must be representable as
> m.f> int, and have type int. Maybe it makes sense to use
> m.f> preprocessor defines for these instead? In addition
> m.f> to fixing ISO C conformance, this would also ensure
> m.f> that the enumerators have a consistent signedness
> m.f> (gcc will choose int for those less than 2^31,
> m.f> and unsigned for those that are greater or equal).
>
> I generally prefer using enumerations to preprocessor
> symbols.

Yes, generally I agree, but unfortunately the standard limits the
values to the range of int, so they aren't suitable for some purposes.

> As far as ISO C conformance goes, casting the literals
> defining these symbols to 'int' might suffice, since
> none of these values would need more than 32 bits
> for their representation; I will take a look.

Converting a value greater than INT_MAX to int is implementation
defined, but perhaps it would work as intended for all implementations
you care about. I also wonder if there are any cases where these large
constants are shifted right. If they were cast to int, the sign
extension could cause problems.

Re: [Elftoolchain-developers] libelf and linux objtool

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

On Sun, Jun 09, 2019 at 02:25:38AM -0700, Michael Forney wrote:

m.f> 1. objtool defines its own elf_open function, used

The elf(3) manual page lists the symbol prefixes in use by
the library.

m.f> It looks like this is because the elftoolchain
m.f> ELF64_R_INFO macro shifts its first argument by 32,
m.f> but objtool passes an unsigned int, so the value was
m.f> getting lost. I resolved this with the diff below.

Applied in r3742, thanks!

m.f> 3. I also noticed that when elf_update recomputes
m.f> the section layout, it leaves the section offset
m.f> of SHT_NOBITS and SHT_NULL sections alone while
m.f> the others are updated. elfutils sets the offset
m.f> of the section based on the ending of the previous
m.f> section. Does this offset have any meaning, or
m.f> is it just arbitrary? Either way, maybe it makes
m.f> sense to set it to the end of the previous section
m.f> to avoid inheriting the value from the original
m.f> section layout.

Would you have a short example program that shows
the difference in behavior of elfutils' libelf and
elftoolchain's libelf?

Per my understanding, for a section of type SHT_NULL,
the rest of the fields in the section header are
undefined.  For a section of type SHT_NOBITS,
the offset and size fields are defined to be a
'conceptual' offset and size of the section; these
values would be set by the application that adds a
SHT_NOBITS section to the object.

When libelf is told to lay out an ELF object (i.e.,
when the ELF_F_LAYOUT flag is not set on the Elf
descriptor), then it isn't clear what the fields of a
SHT_NOBITS section header would need to be set to.

m.f> 4. This is a bit unrelated to objtool,
m.f> but I noticed that elfdefinitions.h contains
m.f> several enums with values that are too big for
m.f> int (specifically, EF_PPC_EMB, SHF_COMDEF,
m.f> SHF_MIPS_STRING, SHF_EXCLUDE, SHF_MASKPROC,
m.f> SHT_LOUSER, and SHT_HIUSER). The C standard says
m.f> that all enumerator values must be representable as
m.f> int, and have type int. Maybe it makes sense to use
m.f> preprocessor defines for these instead? In addition
m.f> to fixing ISO C conformance, this would also ensure
m.f> that the enumerators have a consistent signedness
m.f> (gcc will choose int for those less than 2^31,
m.f> and unsigned for those that are greater or equal).

I generally prefer using enumerations to preprocessor
symbols.

As far as ISO C conformance goes, casting the literals
defining these symbols to 'int' might suffice, since
none of these values would need more than 32 bits
for their representation; I will take a look.

Regards,
Joseph Koshy

[Elftoolchain-developers] libelf and linux objtool

[Michael F. <mf...@mf...>]

Hi,

I'm looking at using elftoolchain instead of elfutils to satisfy the
libelf dependency for objtool used in the linux build process. objtool
is used to add ORC unwind sections to the objects.

So far this is going well, but I have hit a few issues:

1. objtool defines its own elf_open function, used to open an ELF file
by file path, which conflicts with the one used internally by
elftoolchain. I don't think it should be an issue to rename the
function in objtool, and I plan to submit a patch for this.
Additionally, there was one usage of Elf_Scn by the struct tag instead
of the typedef that needed fixing.

2. To check that the .o files were getting transformed in the same way
as with elfutils, I compared the output of `readelf -a` on the results
and noticed that the r_info field in the newly added .rela.orc_unwind
sections differed between the two. It looks like this is because the
elftoolchain ELF64_R_INFO macro shifts its first argument by 32, but
objtool passes an unsigned int, so the value was getting lost. I
resolved this with the diff below.

3. I also noticed that when elf_update recomputes the section layout,
it leaves the section offset of SHT_NOBITS and SHT_NULL sections alone
while the others are updated. elfutils sets the offset of the section
based on the ending of the previous section. Does this offset have any
meaning, or is it just arbitrary? Either way, maybe it makes sense to
set it to the end of the previous section to avoid inheriting the
value from the original section layout.

4. This is a bit unrelated to objtool, but I noticed that
elfdefinitions.h contains several enums with values that are too big
for int (specifically, EF_PPC_EMB, SHF_COMDEF, SHF_MIPS_STRING,
SHF_EXCLUDE, SHF_MASKPROC, SHT_LOUSER, and SHT_HIUSER). The C standard
says that all enumerator values must be representable as int, and have
type int. Maybe it makes sense to use preprocessor defines for these
instead? In addition to fixing ISO C conformance, this would also
ensure that the enumerators have a consistent signedness (gcc will
choose int for those less than 2^31, and unsigned for those that are
greater or equal).

Thanks for any help!

diff --git a/common/elfdefinitions.h b/common/elfdefinitions.h
index 0c207226..d00061ab 100644
--- a/common/elfdefinitions.h
+++ b/common/elfdefinitions.h
@@ -2806,7 +2806,7 @@ typedef struct {

 #define ELF64_R_SYM(I)         ((I) >> 32)
 #define ELF64_R_TYPE(I)                ((I) & 0xFFFFFFFFUL)
-#define ELF64_R_INFO(S,T)      (((S) << 32) + ((T) & 0xFFFFFFFFUL))
+#define ELF64_R_INFO(S,T)      (((Elf64_Xword) (S) << 32) + ((T) &
0xFFFFFFFFUL))

 /*
  * Symbol versioning structures.

Re: [Elftoolchain-developers] (from FreeBSD) Add missing powerpc64 relocation support to libdwarf

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

On Wed, May 29, 2019 at 3:56 AM Brandon Bergren <gi...@bd...> wrote:
> From differential https://reviews.freebsd.org/D20367
> https://svnweb.freebsd.org/base?view=revision&revision=348347
>
> Due to missing relocation support, libdwarf was misparsing unlinked object files, breaking CTF data generation on FreeBSD PowerPC64.
>
> Sending it in directly so it can land here too.
>
> Thanks!

Added in r3741, thanks!

Regards,
Joseph Koshy

[Elftoolchain-developers] (from FreeBSD) Add missing powerpc64 relocation support to libdwarf

[Brandon B. <gi...@bd...>]

>From differential https://reviews.freebsd.org/D20367
https://svnweb.freebsd.org/base?view=revision&revision=348347

Due to missing relocation support, libdwarf was misparsing unlinked object files, breaking CTF data generation on FreeBSD PowerPC64.

Sending it in directly so it can land here too.

Thanks!

-- 
  Brandon Bergren
  gi...@bd...

Re: [Elftoolchain-developers] Building on POWER9

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

nwf> I am trying to build on a POWER9 host and have discovered the need for
nwf> the following trivial patch.  Any chance this could land upstream?

Added in [r3735], thanks.

Regards,
Joseph Koshy

[Elftoolchain-developers] Building on POWER9

[Dr N.W. F. <nw...@ca...>]

Hello elftoolchain-devel.

I am trying to build on a POWER9 host and have discovered the need for 
the
following trivial patch.  Any chance this could land upstream?

Thanks,
--nwf;

diff --git a/common/native-elf-format b/common/native-elf-format
index 79e349c3..08a5da11 100755
--- a/common/native-elf-format
+++ b/common/native-elf-format
@@ -37,6 +37,8 @@ $1 ~ "Machine:" {
              elfarch = "EM_MIPS";
          } else if (match($0, ".*[xX]86[-_]64")) {
              elfarch = "EM_X86_64";
+        } else if (match($0, "PowerPC64")) {
+	    elfarch = "EM_PPC64";
          } else {
              elfarch = "unknown";
          }

Re: [Elftoolchain-developers] libelf: Fix modulo by zero

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

s.n> Following diff fixes modulo by 0 issue found by Coverity scan.
s.n> _libelf_msize() could return 0 on version error.

Thanks for the patch / bug report.

An unexpected version number should be handled better after revision r3732.

Regards,
Joseph Koshy

[Elftoolchain-developers] libelf: Fix modulo by zero

[Sunil N. <sun...@ni...>]

Hi,
Following diff fixes modulo by 0 issue found by Coverity scan.
_libelf_msize() could return 0 on version error.

Needs a review of other callers that assign return value of
_libelf_msize() unchecked in elf_update.c.

diff --git a/libelf/elf_update.c b/libelf/elf_update.c
index 51b3108b..023a229e 100644
--- a/libelf/elf_update.c
+++ b/libelf/elf_update.c
@@ -226,6 +226,7 @@ _libelf_compute_section_extents(Elf *e, Elf_Scn *s, off_t rc)
 		 * memory size of the underlying type.
 		 */
 		msz = _libelf_msize(d->d_type, ec, e->e_version);
+		assert(msz > 0);
 		if (d->d_size % msz) {
 			LIBELF_SET_ERROR(DATA, 0);
 			return (0);
@@ -801,6 +802,7 @@ _libelf_write_scn(Elf *e, unsigned char *nf, struct _Elf_Extent *ex)
 		d = &ld->d_data;
 
 		msz = _libelf_msize(d->d_type, ec, e->e_version);
+		assert(msz > 0);
 
 		if ((uint64_t) rc < sh_off + d->d_off)
 			(void) memset(nf + rc,

Re: [Elftoolchain-developers] SIGFPE in _libelf_compute_section_extents

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

s.n> afl-fuzz generated the attached testcase for elfcopy(1) which causes
s.n> SIGFPE in libelf(3)...

Thanks for the bug report. [r3714] should fix the crash.

Ticket #569 tracks the rest of the work.

Regards,
Joseph Koshy

[Elftoolchain-developers] SIGFPE in _libelf_compute_section_extents

[Sunil N. <sun...@ni...>]

Hi,

afl-fuzz generated the attached testcase for elfcopy(1) which causes
SIGFPE in libelf(3)...

$ elfcopy libelf_sigfpe_testcase
Floating point exception (core dumped)
$ gdb elfcopy elfcopy.core
...
Core was generated by `elfcopy'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x00000365b9bad10d in _libelf_compute_section_extents (e=0x36867841f00, s=0x36867841b00, rc=116)
    at elf_update.c:277
277                         sh_offset % _libelf_falign(elftype, ec)) {
(gdb) bt
#0  0x00000365b9bad10d in _libelf_compute_section_extents (e=0x36867841f00, s=0x36867841b00, rc=116)
    at elf_update.c:277
#1  0x00000365b9baca17 in _libelf_resync_sections (e=0x36867841f00, rc=116, extents=0x7f7ffffbc758)
    at elf_update.c:464
#2  0x00000365b9babd93 in _libelf_resync_elf (e=0x36867841f00, extents=0x7f7ffffbc758)
    at elf_update.c:648
#3  0x00000365b9bab68f in elf_update (e=0x36867841f00, c=ELF_C_NULL) at elf_update.c:1207
#4  0x00000365b9b9466a in copy_phdr (ecp=0x3685465e800) at segments.c:560
#5  0x00000365b9b70738 in create_elf (ecp=0x3685465e800) at main.c:461
#6  0x00000365b9b79330 in create_file (ecp=0x3685465e800,
    src=0x7f7ffffbcd89 "./id:000002,sig:08,src:000000,op:havoc,rep:4", dst=0x0) at main.c:705
#7  0x00000365b9b77e61 in elfcopy_main (ecp=0x3685465e800, argc=2, argv=0x7f7ffffbcc08)
    at main.c:1028
#8  0x00000365b9b723a4 in main (argc=2, argv=0x7f7ffffbcc08) at main.c:1597

[Elftoolchain-developers] question on using elftoolchain to edit an ELF file

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

I have managed to use elftoolchain to read an ELF file and write my
own version of objdump, a disassembler, a loader, etc.  So I can get
it to read ELF files just fine.

What I am having a lot of trouble with is writing ELF files.  I tried
opening the ELF file using

    Elf *elf = elf_begin(fd, ELF_C_RDWR, NULL);

I then just do nothing to the ELF object and then write it back out using:

    elf_update(elf, ELF_C_WRITE);

I end up with a corrupted ELF file.

Any ideas?

My goal is to post-process an ELF file after it has been linked.  I
just need to be able to iterate over the sections and edit them and
then just write the file out again.

Additional question: is there some reason that when opening with
ELF_C_RDWR that we must write the ELF object back out to the same
input file?  I would rather not modify the file in place, but instead
create another one.  Not a show-stopper, it just feels like an
unnecessary restriction.  Perhaps I mis-read the documentation.

Note that I'm using version 0.6.1 instead of version 0.7.1 because the
latter seems to overwrite the system ld when we install it.  One thing
that would really help would be if elftoolchain could be used in-place
without installing it; perhaps this can be done, but I could not get
it to work.  This is not a show-stopper as we can use 0.6.1.

Daniel

[Elftoolchain-developers] Compile error in ld/ld_ehframe.c

[Alexander N. <al...@ya...>]

ld_ehframe.c:745:14: error: left shift of negative value
[-Werror=shift-negative-value]
   ret |= (-1 << shift);

Fix (not sure which include picks limits.h, though):

Index: ld/ld_ehframe.c
===================================================================
--- ld/ld_ehframe.c	(revision 3619)
+++ ld/ld_ehframe.c	(working copy)
@@ -742,7 +742,7 @@
 	} while ((b & 0x80) != 0);
 
 	if (shift < 32 && (b & 0x40) != 0)
-		ret |= (-1 << shift);
+		ret |= (UINT_MAX << shift);
 
 	*dp = src;
 
-- 
Alex

Re: [Elftoolchain-developers] Small elf(3) patch

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

On Tue, Jul 24, 2018 at 10:12 PM, Alexander Nasonov <al...@ya...> wrote:

> elf(3) mentions two deprecated functions:
> elf_getshnum(3) and elf_getsrstrndx(3). The
> patch below replaces them with references to
> elf_getshdrnum(3) and elf_getshdrstrndx(3) and
> it adds a paragraph about elf_getphdrnum(3).

Fixed in [r3617], thanks for the patch!

Regards,
Joseph Koshy

[Elftoolchain-developers] Small elf(3) patch

[Alexander N. <al...@ya...>]

elf(3) mentions two deprecated functions: elf_getshnum(3) and
elf_getsrstrndx(3). The patch below replaces them with references
to elf_getshdrnum(3) and elf_getshdrstrndx(3) and it adds a paragraph
about elf_getphdrnum(3).

-- 
Alex

$ svn diff libelf/elf.3
Index: libelf/elf.3
===================================================================
--- libelf/elf.3        (revision 3616)
+++ libelf/elf.3        (working copy)
@@ -529,9 +529,11 @@
 Compute checksum of an ELF object.
 .It Fn elf_getident
 Retrieve the identification bytes for an ELF object.
-.It Fn elf_getshnum
+.It Fn elf_getshdrnum
 Retrieve the number of sections in an ELF object.
-.It Fn elf_getshstrndx
+.It Fn elf_getphdrnum
+Retrieve the number of program headers in an ELF object.
+.It Fn elf_getshdrstrndx
 Retrieve the section index of the section name string table in
 an ELF object.
 .It Fn elf_hash

[Elftoolchain-developers] changing text address to source *column*

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

I have a program that converts a target text address, `t`, to the
corresponding source filename, line and *column* number.  It works
similar to the the `addr2line` utility that comes with elftoolchain:

1 Fetch Dwarf_Lines with `dwarf_srclines`.
2 For each Dwarf_Line
        3 Fetch address, source filename, line number, and column
          number with dwarf_line{addr,no,off,src}.
        4 If the target address, `t`, equals the line address, then
                5 Set the result to the current Dwarf_Line's
                  filename, line & column number.  Stop searching.
        6 If `t` is greater than the prior Dwarf_Line's address,
          and less than the current Dwarf_Line's address, then
                7 Set the result to the prior Dwarf_Line's
                  filename, line & column number.  Stop searching.
        8 Remember the current address, source, line & column number.

(I have left out an outer loop that walks the "compile unit" DIEs.)

This algorithm seems to agree with the interpretation of the .debug_line
matrix that "DWARF Debugging Information Format, Version 4" describes,
where the row for an instruction is omitted from the matrix if its
content is the same as the prior row.

This produces the right line numbers every time.  The column number,
however, is frequently wrong.  It appears to me that if `t` matches a
line record's address precisely, then that record's column corresponds
to `t`.  However, if the prior record's address and the current record's
address bracket `t`, then the current record's column, rather than the
prior's, corresponds to the target address.

I am using Clang 4.0 and elftoolchain release 0.7.  Maybe this
is just a bug in the way that Clang 4.0 saves columns in the
.debug_line matrix?  It appears that when I enable coverage (--coverage
-fprofile-instr-generate), target addresses (such as function return
addresses) do not match addresses in .debug_line rows precisely.  If I
disable coverage, then there are precise matches.

What do you think, am I misinterpreting the column information?

Dave

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

[Elftoolchain-developers] dwarf_srclines memory management

[Chris J. <ch...@rt...>]

Hi,

I am using libdwarf with RTEMS and I am collecting the list of source for a CU
using 'dwarf_srclines()' however manually cleaning up the memory crashes in
'dwarf_finish()'.

I can see from the libdwarf code I should not clean up because the memory is
being internally handled for me and valgrind confirms the memory has been
cleaned up.

The man page dwarf_srcfiles(3) on FreeBSD and in the eltoolchain source says
dwarf_dealloc(3) should be used however that man pages does not mention srcfiles.

I am not sure what I should be doing here.

Thanks
Chris

Re: [Elftoolchain-developers] Supporting out-of-tree builds

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

nwf> Whoop, spoke too soon.  On FreeBSD, I get
nwf> make: "../mk/../mk/elftoolchain.inc.mk" line 23: Inconsistent operator
nwf> for install
nwf> make: stopped in /mnt/mainline/elftoolchain/common

Thanks for the heads-up. This should be fixed in [r3602]
for FreeBSD.

I haven't got around to checking the other *BSDs yet.

nwf> Secondly, upon closer investigation, I don't think
nwf> libelftc/make-toolchain-version is doing the
nwf> right thing for out-of-tree builds.

Oops, this should be fixed by [r2601].

nwf> I had used ${.PARSEDIR} in my original patch, but that's
nwf> not as widely supported as I might have hoped.

Yes, ${.PARSEDIR} and ${.PARSEFILE} are relatively new, and
are not supported by all the *BSD OSes yet.

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Supporting out-of-tree builds

[Dr N.W. F. <nw...@ca...>]

On 2018-04-12 14:05, Dr N.W. Filardo wrote:
> On 2018-04-11 20:36, Joseph Koshy wrote:
>> Could you please let us know if the tree fails to build (or
>> clean) on your OS version?
> 
> Looks good from here.

Whoop, spoke too soon.  On FreeBSD, I get

> make: "../mk/../mk/elftoolchain.inc.mk" line 23: Inconsistent operator 
> for install
> make: stopped in /mnt/mainline/elftoolchain/common

which I think means that line 23 in elftoolchain.inc.mk,

> install incinstall::	${DESTDIR}${INCSDIR}/${inc}

needs to be replaced with the pair of lines

> install:	${DESTDIR}${INCSDIR}/${inc}
> incinstall:	${DESTDIR}${INCSDIR}/${inc}

Secondly, upon closer investigation, I don't think 
libelftc/make-toolchain-version is doing the
right thing for out-of-tree builds.  While the make rule now gives that 
script the -o path
specifying the output, it still uses ${TOP}, which is incorrect, as it's 
a relative path and
will be interpreted relative to the object directory.  If one has both 
git and svn installed,
this will generate "svn:Unversioned directory" since `svnversion` does 
not output the empty
string as the script expects.  If one does not have svn installed, the 
script will abort,
causing a build failure.

I had used ${.PARSEDIR} in my original patch, but that's not as widely 
supported as I might
have hoped.  Some other mechanism must be identified to find the source 
tree, or the script
must be modified to not fail if both attempts fail, or somesuch.

Cheers,
--nwf;

Re: [Elftoolchain-developers] Supporting out-of-tree builds

[Dr N.W. F. <nw...@ca...>]

On 2018-04-11 20:36, Joseph Koshy wrote:
> Could you please let us know if the tree fails to build (or
> clean) on your OS version?

Looks good from here.

Separately, it seems like SF svn has left 
https://github.com/emaste/elftoolchain in the dust.
Is the latter no longer intended to be used?  (I ask because the build 
scripts in the lab here
use the latter as their upstream for elftoolchain and if it's stale, I 
should let someone know.)

Thanks!
--nwf;

Re: [Elftoolchain-developers] Supporting out-of-tree builds

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

nwf> For various and sundry reasons, I'd like to
nwf> have elftoolchain support out-of-tree builds
nwf> (at the very least, with WITH_TESTS=no and
nwf> WITH_DOCUMENTATION=no).

As of [r3594] the tree should build when .OBJDIR != .CURDIR,
albeit sans the tests and additional documentation.

I've checked the following with Ubuntu+bmake:

1. An in-place build:

   % cd $ELFTOOLCHAIN_SOURCE_DIRECTORY

   % bmake WITH_TESTS=no WITH_DOCUMENTATION=no depend all clean

2. With an obj/ directory:

   % bmake WITH_TESTS=no WITH_DOCUMENTATION=no obj depend all clean

3. Using MAKEOBJDIRPREFIX:

   % bmake MAKEOBJDIRPREFIX=/some/path obj depend all clean

Could you please let us know if the tree fails to build (or
clean) on your OS version?

Regards,
Joseph Koshy

Re: [Elftoolchain-developers] Supporting out-of-tree builds

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

nwf> For various and sundry reasons, I'd like to
nwf> have elftoolchain support out-of-tree builds
nwf> (at the very least, with WITH_TESTS=no and
nwf> WITH_DOCUMENTATION=no).  I took an initial stab at this
nwf> in https://github.com/emaste/elftoolchain/pull/7 , which
nwf> Works For Me (TM).

Thank you for the patch.

Out of curiosity, on what system was this work done?

nwf> That said, I will confess extremely limited experience
nwf> with the BSD make system and convention, so another
nwf> set, or several, of eyes would probably be a good
nwf> idea!  (Is there a good source of documentation for
nwf> the share/mk makefiles?)

There's some documentation at http://www.crufty.net/help/sjg/mk-files.htm.

Regards,
Joseph Koshy

[Elftoolchain-developers] Supporting out-of-tree builds

[Dr N.W. F. <nw...@ca...>]

Hello list,

For various and sundry reasons, I'd like to have elftoolchain support 
out-of-tree builds (at the very least, with WITH_TESTS=no and 
WITH_DOCUMENTATION=no).  I took an initial stab at this in 
https://github.com/emaste/elftoolchain/pull/7 , which Works For Me (TM). 
  That said, I will confess extremely limited experience with the BSD 
make system and convention, so another set, or several, of eyes would 
probably be a good idea!  (Is there a good source of documentation for 
the share/mk makefiles?)

Comments welcome.

Cheers,
--nwf;

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

[Joseph K. <jko...@gm...>]

Thank you for the bug report.

I have filed ticket #557
<https://sourceforge.net/p/elftoolchain/tickets/557/>.

Regards,
Joseph Koshy

On Tue, Mar 6, 2018 at 2:17 AM, David Young <dyo...@po...>
wrote:

> I've found that in elftoolchain 0.7.1, the libdwarf function
> dwarf_get_fde_list_eh() exits with an error when an object has a CIE
> with 'S'-augmentation in its .eh_frame section:
>
> Augmentation: zRS
>
> The augmentation has something to do with signal frames.
>
> I've worked around this by slightly patching libdwarf_frame.c:
>
> --- a/external/bsd/elftoolchain/libdwarf/libdwarf_frame.c
> +++ b/external/bsd/elftoolchain/libdwarf/libdwarf_frame.c
> @@ -143,6 +143,7 @@ _dwarf_frame_parse_lsb_cie_augment(Dwarf_Debug dbg,
> Dwarf_Cie cie,
>         while (*aug_p != '\0') {
>                 switch (*aug_p) {
>                 case 'L':
> +               case 'S':
>                         /* Skip one augment in augment data. */
>                         augdata_p++;
>                         break;
>
>
> Without the patch, an 'S'-augmentation makes
> _dwarf_frame_parse_lsb_cie_augment() exit with an error at the switch's
> default case.
>
> Dave
>
> --
> David Young
> dy...@po...    Urbana, IL    (217) 721-9981
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>

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

[Joseph K. <jko...@gm...>]

On Sat, Mar 10, 2018 at 9:00 PM, Matúš Olekšák <ole...@gm...> wrote:
> Hi,
> I'm trying to compile elf-toolchain on Alpine Linux using bmake and clang,
> and I get this error : "ld: error: zlib is not available". Which is weird in
> many ways, first of all it should be complaining about -lz, on the other
> hand I have installed zlib-dev. Also I'm using lld as linker.
>
> Full log:
> ===> common
> /var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/common/native-elf-format
>> native-elf-format.h || rm native-elf-format.h
> ===> libelf
> cc -pipe -g    -MD -MF elf.d -MT elf.o -I.
> -I/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf
> -I/var/pkg/ress/ress-devel-ext/elf-toolchain/src/elf-toolchain/libelf/../com
> mon -D_FORTIFY_SOURCE=2    -c -pg -DGPROF -DPROF elf.c -o elf.po.o
> ld: error: zlib is not available

At this step of the build you should only be compiling "elf.c", the
linker should not be in the picture.

Which specific version of Alpine Linux are you building on?

Also, are you able to run the linker otherwise?

Regards,
Joseph Koshy