elftoolchain-developers — Discussion on elftoolchain development.

Re: [Elftoolchain-developers] elfcopy vs objcopy

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

On 27 July 2015 at 15:02, Kai Wang <kai...@gm...> wrote:
> Hi Ed,
>
> elfcopy was among the first tools we implemented in the toolchain and we
> thought we could name it elfcopy since we planned to only support ELF
> format.
> Then later when we implemented other tools we figured the "elf" prefix seems
> to be inappropriate, but we were too lazy to change it back.
>
> elfcopy now supports srex, ihex, binary formats etc, and I plan to add PE
> support also.
> So it's more or less a misnomer now... anyway I think it's ok we install it
> as objcopy
> under FreeBSD.

Kai, thanks for the information.

I'll go ahead with the change, which installs as objcopy by default
only on arm64 right now (since the GNU objcopy in FreeBSD base does
not have arm64 support), and enable it by default on all platforms
once all required functionality is implemented. As far as I know PE
support is the only blocking issue -- we need it to produce the x86
UEFI boot bits.

Re: [Elftoolchain-developers] elfcopy vs objcopy

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

Hi Ed,

elfcopy was among the first tools we implemented in the toolchain and we
thought we could name it elfcopy since we planned to only support ELF
format.
Then later when we implemented other tools we figured the "elf" prefix seems
to be inappropriate, but we were too lazy to change it back.

elfcopy now supports srex, ihex, binary formats etc, and I plan to add PE
support also.
So it's more or less a misnomer now... anyway I think it's ok we install it
as objcopy
under FreeBSD.

/Kai

On Mon, Jul 27, 2015 at 8:48 PM, Ed Maste <em...@fr...> wrote:

> I have a review open for FreeBSD[1] to install elfcopy as objcopy, but
> before going ahead I'd like to understand the original motivation for
> giving the tool a distinct name in ELF Tool Chain. We support formats
> other than just ELF, although the list is smaller than GNU objcopy's.
> This is also true for other ELF Tool Chain tools though, and anyone
> installing both ELF Tool Chain and other compatible tools is going to
> need to set PATH appropriately or explicitly choose their tools
> somehow. Given this, is there a reason I shouldn't install it as
> objcopy?
>
> [1] https://reviews.freebsd.org/D2887
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>

[Elftoolchain-developers] elfcopy vs objcopy

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

I have a review open for FreeBSD[1] to install elfcopy as objcopy, but
before going ahead I'd like to understand the original motivation for
giving the tool a distinct name in ELF Tool Chain. We support formats
other than just ELF, although the list is smaller than GNU objcopy's.
This is also true for other ELF Tool Chain tools though, and anyone
installing both ELF Tool Chain and other compatible tools is going to
need to set PATH appropriately or explicitly choose their tools
somehow. Given this, is there a reason I shouldn't install it as
objcopy?

[1] https://reviews.freebsd.org/D2887

[Elftoolchain-developers] libdwarf crash

[Ryan S. <ry...@gm...>]

I've hit a null pointer dereference in libdwarf when opening a particular
ELF file.  The crash is in _dwarf_elf_relocate, specifically here:

http://sourceforge.net/p/elftoolchain/code/HEAD/tree/trunk/libdwarf/libdwarf_elf_init.c#l141

ed->ed_data->d_buf is NULL here.  I single stepped with gdb and found that
this can from elf_getdata() returning a non-NULL ed_data with d_buf is set
to NULL at this line:

http://sourceforge.net/p/elftoolchain/code/HEAD/tree/trunk/libelf/elf_data.c#l143

I have no idea where to go from here.  My test app source can be found here:

https://people.freebsd.org/~rstone/libdwarf_crash/crash.c

A sample ELF file that provokes the crash can be found here:

https://people.freebsd.org/~rstone/libdwarf_crash/dwarf_crash.ko.debug

[Elftoolchain-developers] Capsicumizing ELF Tool Chain tools

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

Capsicum is a lightweight OS capability and sandbox framework
developed at the University of Cambridge Computer Laboratory,
supported by grants from Google, the the FreeBSD Foundation, and
DARPA. Applying Capsicum to ELF Tool Chain tools will mitigate the
harm that will be done if any vulnerabilities in these tools are
exploited.

I've added Capsicum to readelf as a demonstration of what is involved.
The commits are available in my GitHub repository in the cap-readelf
branch: https://github.com/emaste/elftoolchain/tree/cap-readelf .  I
started from SVN revision 3187.

There are three commits there (append .patch or .diff to the URLs to
obtain the diffs if desired):

First, a minor cleanup - readelf has an extraneous test for NULL argv
that I removed.
https://github.com/emaste/elftoolchain/commit/0ddbf792e2dc4da98042dcf1932fc1924433dbcb

Second, a minor refactoring - I moved the opening of the file into
main() and made dump_object operate on an already-opened fd.
https://github.com/emaste/elftoolchain/commit/3af997a181983e9757417e186d16a2fcd23595cc

Third, the Capsicum change itself - the change limits stderr and
stdout to write only, and the input file to fstat and read only. Note
that I enter Capsicum capability mode only for the last file in the
list, as once that's done additional files cannot be opened. This is
not ideal but is awkward to fix, and should be addressed by some
common Capsicum infrastructure in the future.
https://github.com/emaste/elftoolchain/commit/4f66fe9691a214601071fab0f63484a4fcd60a8c

I plan to commit the first two changes (cleanup & refactoring)
shortly. I'd like to get feedback and comments on the capsicum change
before moving forward there.

-Ed

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

On 21 February 2015 at 22:38, Daniel Wilkerson
<dan...@gm...> wrote:
> I am not trolling, I am reporting what I consider to be a bug.

Having the ELF Tool Chain install a library named libdwarf is not a
bug. ELF Tool Chain's libdwarf implements* the same API as the
LGPL-licensed libdwarf from the now-defunct SGI and thus is installed
with the same file name. It may be that it is desirable to have two
implementations of libraries providing the same API installed at the
same time, but that is out of scope of this project and should be
addressed by those packaging the software for a specific operating
system. (Debian's alternatives system, for example.)

I'll not comment on the trademarkability, or lack thereof, of
"libdwarf" as a library file name.

* Or at least, is intended to implement the same API. If or where it
does not, _that_ is a bug.

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

I am not trolling, I am reporting what I consider to be a bug.  Open
source engineers seem very picky about what the license says and then
when it comes to something else, such as trademark, suddenly it is
"trolling".  What if we were discussing BSD vs GPL?  Is that trolling?

I even took the trouble to ask my lawyer on this legal point.  So far
I have legal backing for my point of view and you do not.  You are
making up things where you have no expertise.

If you disagree with me on a point of fact we can discuss it.  However
it is unprofessional of you to accuse me of trolling.  You owe me an
apology.

Daniel

On Sat, Feb 21, 2015 at 7:32 PM, Steve Kargl
<sg...@tr...> wrote:
> On Sat, Feb 21, 2015 at 06:48:58PM -0800, Daniel Wilkerson wrote:
>> On Fri, Feb 20, 2015 at 9:41 PM, Steve Kargl
>> <sg...@tr...> wrote:
>> > On Fri, Feb 20, 2015 at 09:09:39PM -0800, Daniel Wilkerson wrote:
>> >>
>> >> This is just a fact about the ownership of names.
>> >
>> > No one has ownership of the 8-letters libdwarf.
>>
>> Do you have ownership of your name?  The name "libdwarf" is somehow
>> special in that no one owns it, whereas other names may be owned?
>
> Of course, I don't own my name.  If there is a Mr. and Mrs. Kargl
> that wishes to name their son or daughter "Steve Kargl", I cannot
> stop them.  There certainly are a large number of "John Smith"'s
> in the world.
>
> http://en.wikipedia.org/wiki/John_Smith
>
> I won't be responding to anymore of your silly trolling.
>
> --
> Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

[Steve K. <sg...@tr...>]

On Sat, Feb 21, 2015 at 06:48:58PM -0800, Daniel Wilkerson wrote:
> On Fri, Feb 20, 2015 at 9:41 PM, Steve Kargl
> <sg...@tr...> wrote:
> > On Fri, Feb 20, 2015 at 09:09:39PM -0800, Daniel Wilkerson wrote:
> >>
> >> This is just a fact about the ownership of names.
> >
> > No one has ownership of the 8-letters libdwarf.
> 
> Do you have ownership of your name?  The name "libdwarf" is somehow
> special in that no one owns it, whereas other names may be owned?

Of course, I don't own my name.  If there is a Mr. and Mrs. Kargl
that wishes to name their son or daughter "Steve Kargl", I cannot
stop them.  There certainly are a large number of "John Smith"'s
in the world.

http://en.wikipedia.org/wiki/John_Smith

I won't be responding to anymore of your silly trolling.

-- 
Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

On Fri, Feb 20, 2015 at 9:41 PM, Steve Kargl
<sg...@tr...> wrote:
> On Fri, Feb 20, 2015 at 09:09:39PM -0800, Daniel Wilkerson wrote:
>>
>> This is just a fact about the ownership of names.
>
> No one has ownership of the 8-letters libdwarf.

Do you have ownership of your name?  The name "libdwarf" is somehow
special in that no one owns it, whereas other names may be owned?

>> There is a reason the concept of trademark exists.
>
> libdwarf isn't a trademark.

I just spoke to my lawyer about it and there is no reason that it is
not a trademark; note that it does not have to be registered to be a
trademark.  All the core elements of a trademark seem to be there.  He
isn't quite sure how it would go in court -- in particular the
original author of libdwarf would have to assert it, not someone else
-- but you certainly cannot claim without qualification that it is not
a trademark.

Again, Mozilla changed Firebird to Firefox name because Firebird was
taken already, so generally not stomping on other people's project
names, even in the opens source world where we are not always trading
in money, is considered a practice that has value.

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

>>>> on Linux, the instructions are wrong: just using pmake will not work,
>>>> you must invoke it as follows:
>>>>
>>>>     $ NOGCCERROR=1 pmake
>>>
>>> What errors do you see if you do not?
>>
>> Some warning that turns into a build error; I can't recall as it has
>> been a while.  However it was a *lot* of work to figure this out:
>> grepping around through files here and there.  This is the kind of
>> thing that will stop most people, so if you want to increase adoption,
>> just fixing this one point could make a major difference.
>
> As far as I can tell this flag fixes the build by disabling -Werror.
> We should probably do two things here: fix the warnings that were
> promoted into errors, and also only enable -Werror on the platforms
> normally used by developers (i.e., in my case FreeBSD and Clang).

Well, instead of predicating it on the platform, how about making
-Werror off by default and only turning it on using an environment
variable?  Right now it is the reverse.

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

[Steve K. <sg...@tr...>]

On Fri, Feb 20, 2015 at 09:09:39PM -0800, Daniel Wilkerson wrote:
> 
> This is just a fact about the ownership of names.

No one has ownership of the 8-letters libdwarf.  

> There is a reason the concept of trademark exists.

libdwarf isn't a trademark.

No one is telling you where to install the software.
Put it in /usr/trademark/elftoolchain/lib.  Now,
read your compiler documentation about the -L option.

Your messages beg the question: "what other libdwarf
is elftoolchain libdwarf being confused with on your
system?"  More importantly are you insisting that the
developers of the other libdwarf rename their library
because of trademark?

-- 
Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

>> > Or, are you saying that all non-Dennis-Ritchie derived C compiler
>> > must call their runtime library something other than libc?
>> >
>> If you install it in the global namespace as "libdwarf" and it
>> therefore creates an anti-dependency on the original, then, yes, you
>> have stolen the name of the previous project.  If instead you
>> installed it under some elftoolchain/libdwarf, or maybe
>> elftoolchain-libdwarf, that might be different.
>
> So, do you have a libc and is that Dennis Ritchie's libc?
> There's no stealing.  If this upset you so greatly, then
> use the original libdwarf.

I am attempting to have a professional conversation about engineering,
not a conversation about who is more upset.

This is just a fact about the ownership of names.  There is a reason
the concept of trademark exists.  You are not allowed to start another
business having the same name in the same market as another business
as you have taken a name that they did work to establish and created
confusion in the marketplace.  That's the reason Mozilla changed
Firebird to Firefox, to cite one prominent example.

http://en.wikipedia.org/wiki/Trademark
"The essential function of a trademark is to exclusively identify the
commercial source or origin of products or services, so a trademark,
properly called, indicates source or serves as a badge of origin. In
other words, trademarks serve to identify a particular business as the
source of goods or services."

It is also a conversation about not creating anti-dependencies in the
global namespace.  The fact that there are multiple implementations of
libc is not a problem.  The fact that they all install themselves
under the same name is a very real problem when attempting to
piecewise upgrade a system; I have had to not upgrade software just
for this reason.  Namespace anti-dependencies are a gratuitous
difficulty that have no fundamental reason to exist.  There are enough
fundamental engineering problems without us adding gratuitous
engineering problems.

So for example, installing under a name like elftoolchain-libdwarf is
more helpful than just libdwarf as it establishes whose libdwarf it
is.  If you then want to make a softlink from libdwarf to
elftoochain-libdwarf on your system then that is easy to do, and could
be a question asked as part of the install process.  This is the
solution we use for web browsers: they each have their own name and
then you are asked which one you would like to be the default.

Daniel

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

[Steve K. <sg...@tr...>]

On Fri, Feb 20, 2015 at 07:33:51PM -0800, Daniel Wilkerson wrote:
> 
> On Fri, Feb 20, 2015 at 3:01 PM, Steve Kargl
> <sg...@tr...> wrote:
> > On Fri, Feb 20, 2015 at 02:10:39PM -0800, Daniel Wilkerson wrote:
> >>
> >> Another major bug is using the name libdwarf when a libdwarf project
> >> already exists which you are explicitly imitating: you are basically
> >> violating his trademark.  Firebird changed their name to Firefox just
> >> because another project existed.
> >>
> >
> > Huh?  The project name is "The Elf Tool Chaini Project".
> > The fact that it contains a library named libdwarf does
> > not violate anything.
> >
> > Or, are you saying that all non-Dennis-Ritchie derived C compiler
> > must call their runtime library something other than libc?
> >
> If you install it in the global namespace as "libdwarf" and it
> therefore creates an anti-dependency on the original, then, yes, you
> have stolen the name of the previous project.  If instead you
> installed it under some elftoolchain/libdwarf, or maybe
> elftoolchain-libdwarf, that might be different.

So, do you have a libc and is that Dennis Ritchie's libc?
There's no stealing.  If this upset you so greatly, then
use the original libdwarf.

-- 
Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

If you install it in the global namespace as "libdwarf" and it
therefore creates an anti-dependency on the original, then, yes, you
have stolen the name of the previous project.  If instead you
installed it under some elftoolchain/libdwarf, or maybe
elftoolchain-libdwarf, that might be different.

Daniel

On Fri, Feb 20, 2015 at 3:01 PM, Steve Kargl
<sg...@tr...> wrote:
> On Fri, Feb 20, 2015 at 02:10:39PM -0800, Daniel Wilkerson wrote:
>>
>> Another major bug is using the name libdwarf when a libdwarf project
>> already exists which you are explicitly imitating: you are basically
>> violating his trademark.  Firebird changed their name to Firefox just
>> because another project existed.
>>
>
> Huh?  The project name is "The Elf Tool Chaini Project".
> The fact that it contains a library named libdwarf does
> not violate anything.
>
> Or, are you saying that all non-Dennis-Ritchie derived C compiler
> must call their runtime library something other than libc?
>
> --
> Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

On 20 February 2015 at 18:01, Steve Kargl
<sg...@tr...> wrote:
> On Fri, Feb 20, 2015 at 02:10:39PM -0800, Daniel Wilkerson wrote:
>>
>> Another major bug is using the name libdwarf when a libdwarf project
>> already exists which you are explicitly imitating: you are basically
>> violating his trademark.  Firebird changed their name to Firefox just
>> because another project existed.
>>
>
> Huh?  The project name is "The Elf Tool Chaini Project".
> The fact that it contains a library named libdwarf does
> not violate anything.

Just as the LGPL'd project from mr511.de and elfutils and the ELF Tool
Chain all provide a libelf that is (intended to be) a compatible
implementation of the SVR4 version.

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

[Steve K. <sg...@tr...>]

On Fri, Feb 20, 2015 at 02:10:39PM -0800, Daniel Wilkerson wrote:
> 
> Another major bug is using the name libdwarf when a libdwarf project
> already exists which you are explicitly imitating: you are basically
> violating his trademark.  Firebird changed their name to Firefox just
> because another project existed.
> 

Huh?  The project name is "The Elf Tool Chaini Project".
The fact that it contains a library named libdwarf does
not violate anything.

Or, are you saying that all non-Dennis-Ritchie derived C compiler
must call their runtime library something other than libc?

-- 
Steve

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

On 20 February 2015 at 17:10, Daniel Wilkerson
<dan...@gm...> wrote:
>
> Ok, but at least do a 0.6.2 release that at least includes this fix to
> a major bug.  That is, do bug fix releases when show-stopper bugs are
> fixed so that the public release is at least not *known* to be buggy.
> Or just don't do public releases at all and tell people to get the
> latest version from svn; I do this on some projects.

Ok, that's a fair point. I've only been an elftoolchain committer for
a few days, so I'll defer to the others on this.

>>> on Linux, the instructions are wrong: just using pmake will not work,
>>> you must invoke it as follows:
>>>
>>>     $ NOGCCERROR=1 pmake
>>
>> What errors do you see if you do not?
>
> Some warning that turns into a build error; I can't recall as it has
> been a while.  However it was a *lot* of work to figure this out:
> grepping around through files here and there.  This is the kind of
> thing that will stop most people, so if you want to increase adoption,
> just fixing this one point could make a major difference.

As far as I can tell this flag fixes the build by disabling -Werror.
We should probably do two things here: fix the warnings that were
promoted into errors, and also only enable -Werror on the platforms
normally used by developers (i.e., in my case FreeBSD and Clang).

> Again, I have not tried it for a while, so I no longer recall exactly,
> but I tried using -I and -L in the obvious ways and some of your
> internal includes didn't find each other.  If the "install in a local
> non-default directory" instructions from INSTALL work, then that
> provides a way for people to build but not override the default
> install.

Ok - I don't see these errors, so I won't be able to make any progress
without details about what's failing.

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

>> The latest public release of elftoolchain, elftoolchain-0.6.1, has a
>> bug in that it does not process DWARF4 correctly; get it as follows:
>
> Right now elftoolchain is still a reasonably fast-moving target, so
> using a source snapshot is likely to be preferable for the near
> future. I don't see this as a workaround, but rather a natural
> consequence of elftoolchain's current stage of development.

Ok, but at least do a 0.6.2 release that at least includes this fix to
a major bug.  That is, do bug fix releases when show-stopper bugs are
fixed so that the public release is at least not *known* to be buggy.
Or just don't do public releases at all and tell people to get the
latest version from svn; I do this on some projects.

>> The build process will stop and tell you to do this if you do not do
>> it initially:
>>
>>     Please download the distribution from:
>>     http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet3.8-src.\
>> tar.gz
>>     and unpack it into directory "../../test/tet/tet3.8".
>>
>> The tet3.8-src.tar.gz file unpacks into a dir named tet3.8 and the
>> message above means to put it into elftoolchain-0.6.1/test/tet/.
>
> This could be automated, but doesn't seem like a big hurdle to me, and
> a number of other projects handle third-party dependencies in a
> similar way. I think some test suite rework might be planned and
> perhaps this can be addressed then.

People are in the habit of setting up a build and then walking away
and expecting to come back to a finished build.  If you don't do this,
the build process goes on for quite a while and then stops saying to
install the above-mentioned code.  That's really annoying.  Instead,
look for the dependency up front and if it is missing, tell the user
right away.

>> There does not seem to be a configure step.  Note that when building
>> on Linux, the instructions are wrong: just using pmake will not work,
>> you must invoke it as follows:
>>
>>     $ NOGCCERROR=1 pmake
>
> What errors do you see if you do not?

Some warning that turns into a build error; I can't recall as it has
been a while.  However it was a *lot* of work to figure this out:
grepping around through files here and there.  This is the kind of
thing that will stop most people, so if you want to increase adoption,
just fixing this one point could make a major difference.

>> You must install elftoolchain in order to build against it; it is not
>> enough to just use +-I+ and +-L+ flags as the internal headers within
>> elftoolchain will not find each other.
>
> The tools provided with elftoolchain (nm, size, etc.) do build against
> the just-built libelf and libdwarf, so it is certainly possible. What
> command line did you try, and what error did you see?

Again, I have not tried it for a while, so I no longer recall exactly,
but I tried using -I and -L in the obvious ways and some of your
internal includes didn't find each other.  If the "install in a local
non-default directory" instructions from INSTALL work, then that
provides a way for people to build but not override the default
install.

Another major bug is using the name libdwarf when a libdwarf project
already exists which you are explicitly imitating: you are basically
violating his trademark.  Firebird changed their name to Firefox just
because another project existed.

Daniel

Re: [Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

On 20 February 2015 at 15:30, Daniel Wilkerson
<dan...@gm...> wrote:
> Ed, this is from the Ubuntu install instructions for a project where I
> am using elftoolchain.  Per our discussion, if you want people using
> Linux to use elftoolchain, you might want to reduce the number of
> workarounds in this list.

I hope that by publishing your list of workarounds you can save other
Linux users some effort in trying elftoolchain.

To be clear, I'd be happy if Linux users try out elftoolchain so that
it gets broader exposure and testing, but have no direct need for
that. I'd be happy to help shepherd in patches from Linux users to
address these issues.

> The latest public release of elftoolchain, elftoolchain-0.6.1, has a
> bug in that it does not process DWARF4 correctly; get it as follows:

Right now elftoolchain is still a reasonably fast-moving target, so
using a source snapshot is likely to be preferable for the near
future. I don't see this as a workaround, but rather a natural
consequence of elftoolchain's current stage of development.

>     $ sudo apt-get install zlib1g-dev

Updated in the INSTALL document now.

> The build process will stop and tell you to do this if you do not do
> it initially:
>
>     Please download the distribution from:
>     http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet3.8-src.\
> tar.gz
>     and unpack it into directory "../../test/tet/tet3.8".
>
> The tet3.8-src.tar.gz file unpacks into a dir named tet3.8 and the
> message above means to put it into elftoolchain-0.6.1/test/tet/.

This could be automated, but doesn't seem like a big hurdle to me, and
a number of other projects handle third-party dependencies in a
similar way. I think some test suite rework might be planned and
perhaps this can be addressed then.

> There does not seem to be a configure step.  Note that when building
> on Linux, the instructions are wrong: just using pmake will not work,
> you must invoke it as follows:
>
>     $ NOGCCERROR=1 pmake

What errors do you see if you do not?

> You must install elftoolchain in order to build against it; it is not
> enough to just use +-I+ and +-L+ flags as the internal headers within
> elftoolchain will not find each other.

The tools provided with elftoolchain (nm, size, etc.) do build against
the just-built libelf and libdwarf, so it is certainly possible. What
command line did you try, and what error did you see?

> elftoolchain-0.6.1 has a bug where the install target does not install
> the header files into /usr/include, so I had to do it myself; I don't
> know if this is required for the version above, but doing it did not
> seem to hurt, so you might as well.

As far as I can see header install rules are just omitted for Linux
for some reason. I hope that the other elftoolchain developers can
provide some insight.

[Elftoolchain-developers] my current list of workarounds to get elftoolchain to install on Ubuntu

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

Ed, this is from the Ubuntu install instructions for a project where I
am using elftoolchain.  Per our discussion, if you want people using
Linux to use elftoolchain, you might want to reduce the number of
workarounds in this list.

Daniel

== Installing ELF Tool Chain

We depend on the http://sourceforge.net/projects/elftoolchain/[ELF
Tool Chain] project.

The latest public release of elftoolchain, elftoolchain-0.6.1, has a
bug in that it does not process DWARF4 correctly; get it as follows:

    $ svn checkout -r 3164
      svn://svn.code.sf.net/p/elftoolchain/code/trunk
      elftoolchain-code

Gcc switched to DWARF4 at some point before gcc 4.9.2 and so you need
at least that version of elftoolchain to parse its DWARF output; it is
likely that any revision past that one of 2015-02-18 17:20:12 -0800
will work.

The elftoolchain-0.6.1/INSTALL will tell you what dependencies to
install:

    $ sudo apt-get install bison flex gcc libarchive-dev m4 pmake \
      libexpat1-dev python-yaml sharutils

However you will also need this, which is not documented:

    $ sudo apt-get install zlib1g-dev

The build process will stop and tell you to do this if you do not do
it initially:

    Please download the distribution from:
    http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet3.8-src.\
tar.gz
    and unpack it into directory "../../test/tet/tet3.8".

The tet3.8-src.tar.gz file unpacks into a dir named tet3.8 and the
message above means to put it into elftoolchain-0.6.1/test/tet/.

There does not seem to be a configure step.  Note that when building
on Linux, the instructions are wrong: just using pmake will not work,
you must invoke it as follows:

    $ NOGCCERROR=1 pmake

You must install elftoolchain in order to build against it; it is not
enough to just use +-I+ and +-L+ flags as the internal headers within
elftoolchain will not find each other.

    $ sudo pmake install

The INSTALL file provides a way to install elftoolchain in a place
other than the default, but I have not tried it.

elftoolchain-0.6.1 has a bug where the install target does not install
the header files into /usr/include, so I had to do it myself; I don't
know if this is required for the version above, but doing it did not
seem to hurt, so you might as well.

    $ cd elftoolchain-0.6.1/
    $ sudo cp ./libelf/libelf.h ./libelf/gelf.h
      ./common/elfdefinitions.h ./libelftc/libelftc.h
      ./libdwarf/libdwarf.h ./libdwarf/dwarf.h /usr/include/

Re: [Elftoolchain-developers] a version of gcc 4.9.2 is generating DWARF source lines that elftoolchain does not parse but objdump will

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

Kai, that seems to have worked.  Thank you!  I was really stuck if you
hadn't fixed that.  When is the fix you just made going to be
released?  It seems for now people have to get it from the svn repo on
sourceforge.

FYI here are my current install instructions for my project for how to
install elftoolchain on 64-bit Ubuntu.  As you can see, I seem to have
to work around a lot of stuff that seems unnecessary.  I don't know if
all of these are still relevant, but they used to be.  You do have
install instructions for installing somewhere other than the default
system locations, so perhaps that paragraph is not relevant.

----
The elftoolchain-0.6.1/INSTALL will tell you what dependencies to
install; for the latest Ubuntu, this seems to be what they want and
seems to work:

    $ sudo apt-get install bison flex gcc libarchive-dev m4 pmake \
      libexpat1-dev python-yaml sharutils zlib1g-dev

The build process will stop and tell you to do this if you do not do
it initially:

    Please download the distribution from:
    http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet3.8-src.tar.gz
    and unpack it into directory "../../test/tet/tet3.8".

The tet3.8-src.tar.gz file unpacks into a dir named tet3.8 and the
message above means to put it into elftoolchain-0.6.1/test/tet/.

There does not seem to be a configure step.  Note that when building
on Linux, the instructions are wrong: just using pmake will not work,
you must invoke it as follows:

    $ NOGCCERROR=1 pmake

You must install elftoolchain in order to build against it; it is not
enough to just use +-I+ and +-L+ flags as the internal headers within
elftoolchain will not find each other.  Or, if there is a way to do
it, I do not know how.

    $ sudo pmake install

The current version of elftoolchain-0.6.1 has a bug where the install
target does not install the header files into /usr/include, so you
have to do it yourself.

    $ cd elftoolchain-0.6.1/
    $ sudo cp ./libelf/libelf.h ./libelf/gelf.h
      ./common/elfdefinitions.h ./libelftc/libelftc.h
      ./libdwarf/libdwarf.h ./libdwarf/dwarf.h /usr/include/



On Wed, Feb 18, 2015 at 6:38 PM, Daniel Wilkerson
<dan...@gm...> wrote:
> That got me past that build error; still building.
>
> I suggest you add that to the INSTALL dependencies list; I don't see it there.
>
> Also, you might want to give the URL for the tet project in the INSTALL.
>
> On Wed, Feb 18, 2015 at 6:33 PM, Kai Wang <kai...@gm...> wrote:
>> Did you install the zlib dev version?
>>
>> sudo apt-get install zlib1g-dev
>>
>> /Kai
>>
>> On Thu, Feb 19, 2015 at 3:31 AM, Daniel Wilkerson
>> <dan...@gm...> wrote:
>>>
>>> What is -lz?  I did an apt-get install zlibc, but that isn't it.
>>>
>>> cc  -L../libelf -L../libelftc  -o ar ar.o read.o util.o write.o
>>> acplex.o acpyacc.o -larchive -lelftc -lelf -lz
>>> /usr/bin/ld: cannot find -lz
>>> collect2: error: ld returned 1 exit status
>>> *** Error code 1
>>>
>>> Stop.
>>> pmake[1]: stopped in /home/dsw/elftoolchain-code-0.6.1-r3164/ar
>>> *** Error code 1
>>>
>>> Stop.
>>> pmake: stopped in /home/dsw/elftoolchain-code-0.6.1-r3164
>>>
>>> On Wed, Feb 18, 2015 at 5:21 PM, Kai Wang <kai...@gm...> wrote:
>>> > Daniel,
>>> >
>>> > This should be fixed in r3164. Could you verify?
>>> >
>>> > DWARF4 line section added a new field in the header and I missed that.
>>> > More work will probably be needed later but now the parsing part should
>>> > be
>>> > ok.
>>> >
>>> > /Kai
>>> >
>>> > On Wed, Feb 18, 2015 at 7:31 AM, Daniel Wilkerson
>>> > <dan...@gm...> wrote:
>>> >>
>>> >> I tried using elftoolchain to parse the dwarf source line annotation
>>> >> output of vanilla gcc 4.9.2 and it works just fine.  In contrast, as
>>> >> stated below, parsing the output of the riscv-gcc 4.9.2 produces the
>>> >> error below: "Line info section too short".  Clearly this is a problem
>>> >> introduced by the riscv people.
>>> >>
>>> >> However, objdump parses the dwarf source line output of both compilers
>>> >> without complaint.  So if I report the bug to the riscv people at
>>> >> Berkeley that their compiler produces output that objdump likes but
>>> >> that elftoolchain will not parse, they can easily say that this is a
>>> >> bug in elftoolchain.
>>> >>
>>> >> I am basically blocked on this issue, so I am now in bug hell.  Any
>>> >> assistance would be greatly appreciated.  Can elftoolchain be made a
>>> >> bit more tolerant?  I will also write the riscv people.
>>> >>
>>> >> On Mon, Feb 16, 2015 at 1:07 PM, Daniel Wilkerson
>>> >> <dan...@gm...> wrote:
>>> >> > The RISC-V people at Berkeley have modified gcc 4.9.2 to target the
>>> >> > RISC-V ISA.  I have been able to use elftoolchain to parse the output
>>> >> > of previous versions of gcc which they have hacked, but not this one.
>>> >> > When I try to get the dwarf source lines from ELF they produce, as
>>> >> > follows:
>>> >> >
>>> >> > int const dwarf_src_res =
>>> >> >       dwarf_srclines(root_die, &lines, &num_lines, &dwarf_error);
>>> >> > . . .
>>> >> > fprintf(stderr, "Dwarf_Source_Lines:"
>>> >> >             "DW_DLE_NO_ENTRY:%d, DW_DLV_OK:%d, "
>>> >> >             "dwarf_src_res: %d\n",
>>> >> >             DW_DLE_NO_ENTRY, DW_DLV_OK, dwarf_src_res);
>>> >> > . . .
>>> >> > dwarf_errmsg(dwarf_error)
>>> >> >
>>> >> > I get a dwarf_src_res of 1:
>>> >> > Dwarf_Source_Lines:DW_DLE_NO_ENTRY:4, DW_DLV_OK:0, dwarf_src_res: 1
>>> >> >
>>> >> > And this error message:
>>> >> > Line info section too short [_dwarf_lineno_init(335)]
>>> >> >
>>> >> > However objdump reads and will output the source lines of the same
>>> >> > ELF
>>> >> > file.
>>> >> >
>>> >> > Is anyone else getting this result parsing the DWARF source lines
>>> >> > coming from, say, unmodified gcc 4.9.2 ?
>>> >> >
>>> >> > Daniel
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> >> from Actuate! Instantly Supercharge Your Business Reports and
>>> >> Dashboards
>>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> >> more
>>> >> Get technology previously reserved for billion-dollar corporations,
>>> >> FREE
>>> >>
>>> >>
>>> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> >> _______________________________________________
>>> >> Elftoolchain-developers mailing list
>>> >> Elf...@li...
>>> >> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>>> >
>>> >
>>
>>

Re: [Elftoolchain-developers] a version of gcc 4.9.2 is generating DWARF source lines that elftoolchain does not parse but objdump will

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

Daniel,

This should be fixed in r3164. Could you verify?

DWARF4 line section added a new field in the header and I missed that.
More work will probably be needed later but now the parsing part should be
ok.

/Kai

On Wed, Feb 18, 2015 at 7:31 AM, Daniel Wilkerson <
dan...@gm...> wrote:

> I tried using elftoolchain to parse the dwarf source line annotation
> output of vanilla gcc 4.9.2 and it works just fine.  In contrast, as
> stated below, parsing the output of the riscv-gcc 4.9.2 produces the
> error below: "Line info section too short".  Clearly this is a problem
> introduced by the riscv people.
>
> However, objdump parses the dwarf source line output of both compilers
> without complaint.  So if I report the bug to the riscv people at
> Berkeley that their compiler produces output that objdump likes but
> that elftoolchain will not parse, they can easily say that this is a
> bug in elftoolchain.
>
> I am basically blocked on this issue, so I am now in bug hell.  Any
> assistance would be greatly appreciated.  Can elftoolchain be made a
> bit more tolerant?  I will also write the riscv people.
>
> On Mon, Feb 16, 2015 at 1:07 PM, Daniel Wilkerson
> <dan...@gm...> wrote:
> > The RISC-V people at Berkeley have modified gcc 4.9.2 to target the
> > RISC-V ISA.  I have been able to use elftoolchain to parse the output
> > of previous versions of gcc which they have hacked, but not this one.
> > When I try to get the dwarf source lines from ELF they produce, as
> > follows:
> >
> > int const dwarf_src_res =
> >       dwarf_srclines(root_die, &lines, &num_lines, &dwarf_error);
> > . . .
> > fprintf(stderr, "Dwarf_Source_Lines:"
> >             "DW_DLE_NO_ENTRY:%d, DW_DLV_OK:%d, "
> >             "dwarf_src_res: %d\n",
> >             DW_DLE_NO_ENTRY, DW_DLV_OK, dwarf_src_res);
> > . . .
> > dwarf_errmsg(dwarf_error)
> >
> > I get a dwarf_src_res of 1:
> > Dwarf_Source_Lines:DW_DLE_NO_ENTRY:4, DW_DLV_OK:0, dwarf_src_res: 1
> >
> > And this error message:
> > Line info section too short [_dwarf_lineno_init(335)]
> >
> > However objdump reads and will output the source lines of the same ELF
> file.
> >
> > Is anyone else getting this result parsing the DWARF source lines
> > coming from, say, unmodified gcc 4.9.2 ?
> >
> > Daniel
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Elftoolchain-developers mailing list
> Elf...@li...
> https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
>

Re: [Elftoolchain-developers] a version of gcc 4.9.2 is generating DWARF source lines that elftoolchain does not parse but objdump will

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

I tried using elftoolchain to parse the dwarf source line annotation
output of vanilla gcc 4.9.2 and it works just fine.  In contrast, as
stated below, parsing the output of the riscv-gcc 4.9.2 produces the
error below: "Line info section too short".  Clearly this is a problem
introduced by the riscv people.

However, objdump parses the dwarf source line output of both compilers
without complaint.  So if I report the bug to the riscv people at
Berkeley that their compiler produces output that objdump likes but
that elftoolchain will not parse, they can easily say that this is a
bug in elftoolchain.

I am basically blocked on this issue, so I am now in bug hell.  Any
assistance would be greatly appreciated.  Can elftoolchain be made a
bit more tolerant?  I will also write the riscv people.

On Mon, Feb 16, 2015 at 1:07 PM, Daniel Wilkerson
<dan...@gm...> wrote:
> The RISC-V people at Berkeley have modified gcc 4.9.2 to target the
> RISC-V ISA.  I have been able to use elftoolchain to parse the output
> of previous versions of gcc which they have hacked, but not this one.
> When I try to get the dwarf source lines from ELF they produce, as
> follows:
>
> int const dwarf_src_res =
>       dwarf_srclines(root_die, &lines, &num_lines, &dwarf_error);
> . . .
> fprintf(stderr, "Dwarf_Source_Lines:"
>             "DW_DLE_NO_ENTRY:%d, DW_DLV_OK:%d, "
>             "dwarf_src_res: %d\n",
>             DW_DLE_NO_ENTRY, DW_DLV_OK, dwarf_src_res);
> . . .
> dwarf_errmsg(dwarf_error)
>
> I get a dwarf_src_res of 1:
> Dwarf_Source_Lines:DW_DLE_NO_ENTRY:4, DW_DLV_OK:0, dwarf_src_res: 1
>
> And this error message:
> Line info section too short [_dwarf_lineno_init(335)]
>
> However objdump reads and will output the source lines of the same ELF file.
>
> Is anyone else getting this result parsing the DWARF source lines
> coming from, say, unmodified gcc 4.9.2 ?
>
> Daniel

[Elftoolchain-developers] a version of gcc 4.9.2 is generating DWARF source lines that elftoolchain does not parse but objdump will

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

The RISC-V people at Berkeley have modified gcc 4.9.2 to target the
RISC-V ISA.  I have been able to use elftoolchain to parse the output
of previous versions of gcc which they have hacked, but not this one.
When I try to get the dwarf source lines from ELF they produce, as
follows:

int const dwarf_src_res =
      dwarf_srclines(root_die, &lines, &num_lines, &dwarf_error);
. . .
fprintf(stderr, "Dwarf_Source_Lines:"
            "DW_DLE_NO_ENTRY:%d, DW_DLV_OK:%d, "
            "dwarf_src_res: %d\n",
            DW_DLE_NO_ENTRY, DW_DLV_OK, dwarf_src_res);
. . .
dwarf_errmsg(dwarf_error)

I get a dwarf_src_res of 1:
Dwarf_Source_Lines:DW_DLE_NO_ENTRY:4, DW_DLV_OK:0, dwarf_src_res: 1

And this error message:
Line info section too short [_dwarf_lineno_init(335)]

However objdump reads and will output the source lines of the same ELF file.

Is anyone else getting this result parsing the DWARF source lines
coming from, say, unmodified gcc 4.9.2 ?

Daniel

Re: [Elftoolchain-developers] make options

[stephen T. <ste...@gm...>]

>
> In case autotools is an option for you (which will in the end create
> a GNU make compatible makefile), have a look at autotools support in
> ticket #321 : http://sourceforge.net/p/elftoolchain/tickets/321/#cf36.
>
>
Im not opposed to autotools as long as i dont have to install the tools.
The configure code is in a number of apps i use and is perfectly acceptable
to me (no allergy to GNU although i do consider more relaxed licenses
preferred)


> Most probably that supplied patch is a bit outdated after 2+ years.
>
> It is actually part of:
>
> svn diff svn://
> svn.riscos.info/gccsdk/trunk/tools/elftoolchain/{upstream-trunk,current-trunk}
>
> 'upstream-trunk' follows sf.net svn trunk but I'm no longer regulary
>

Yea, i'm guessing this patch is too old to work correctly as well. I will
probobly have to download the tools to generate a makefile or autotools and
i definitely want to make it as generic as possible to weather changes.
Since it looks like i might be waiting a bit for any patches to go mainline
assuming they do at all. That patch has been waiting for several years
still open.

Thanks for pointing that patch out!