Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1448 > unrolled thread

ELF and DWARF tools ?

Started by"John R. Levine" <johnl@iecc.com>
First post2014-12-29 00:42 -0500
Last post2014-12-30 18:18 -0500
Articles 5 — 5 participants

Back to article view | Back to comp.compilers


Contents

  ELF and DWARF tools ? "John R. Levine" <johnl@iecc.com> - 2014-12-29 00:42 -0500
    Re: ELF and DWARF tools ? C Bergström <cbergstrom@pathscale.com> - 2014-12-29 13:22 +0700
    Re: ELF and DWARF tools ? Hans Aberg <haberg-news@telia.com> - 2014-12-29 10:38 +0100
    Re: ELF and DWARF tools ? Walter Banks <walter@bytecraft.com> - 2014-12-29 08:05 -0500
      Re: ELF and DWARF tools ? Charles Chester <cc.63dw@gmail.com> - 2014-12-30 18:18 -0500

#1448 — ELF and DWARF tools ?

From"John R. Levine" <johnl@iecc.com>
Date2014-12-29 00:42 -0500
SubjectELF and DWARF tools ?
Message-ID<14-12-005@comp.compilers>
I am working on a project which involves building a compiler toolchain for
yet another architecture.  The obvious object format to use is ELF and
DWARF, and I'm trying to figure out the least painful way to do that.

One possibility is the GNU bfd/binutils route.  That's very complete, and
very large.  Another is libelf and libdwarf, which seem (from googlage) to
have good reputations.

Because I am a lazy programmer, I would like to do as much of the
prototyping as I can in python.  I see PyBFD which claims that it wraps
much of the BFD libraries.

Any suggestions?  Are there python wrappers for libelf or libdwarf?  How
hard is it to add a new architecture to BFD or libelf?

Signed,
Bitwhacked

[toc] | [next] | [standalone]


#1449

FromC Bergström <cbergstrom@pathscale.com>
Date2014-12-29 13:22 +0700
Message-ID<14-12-006@comp.compilers>
In reply to#1448
On Mon, Dec 29, 2014 at 12:42 PM, John R. Levine <johnl@iecc.com> wrote:
>
> I am working on a project which involves building a compiler toolchain for
> yet another architecture.  The obvious object format to use is ELF and
> DWARF, and I'm trying to figure out the least painful way to do that. ...

The llvm family of code is becoming more complete in terms of a full
GNU replacement. That isn't the land of python, but you're going to
have to go outside of that anyway for actual compiler/toolchain work.
(LLVM has a builtin DWARF parser)

I'm not a fan of llvm, but the codebase does have a "not bad" design
in terms of ease of portability. Assuming your arch isn't VLIW I
wouldn't expect too much hell.

If gcc isn't a forced requirement out of the gate maybe give it a go.

/*
Side note: there's 2 "libdwarfs" floating around.. the one from SGI
and the BSD implementation, if licensing makes any difference..  I've
worked with the later
https://github.com/pathscale/libdwarf-bsd
*/

[toc] | [prev] | [next] | [standalone]


#1450

FromHans Aberg <haberg-news@telia.com>
Date2014-12-29 10:38 +0100
Message-ID<14-12-007@comp.compilers>
In reply to#1448
On 2014/12/29 06:42, John R. Levine wrote:

> Are there python wrappers for libelf or libdwarf?  How
> hard is it to add a new architecture to BFD or libelf?

LLVM can be used as an intermediate format, a search shows.

[toc] | [prev] | [next] | [standalone]


#1451

FromWalter Banks <walter@bytecraft.com>
Date2014-12-29 08:05 -0500
Message-ID<14-12-008@comp.compilers>
In reply to#1448
"John R. Levine" wrote:

> I am working on a project which involves building a compiler toolchain for
> yet another architecture.  The obvious object format to use is ELF and
> DWARF, and I'm trying to figure out the least painful way to do that. ...

This isn't going to help much. I have plenty of coding scars to show for
re-implementing compiler elf/dwarf support from scratch. Most of
what I found comes from a number of issues.

1) Lack of comprehensive elf/dwarf documentation. There are several
documents out there that help but often critical details are missing.
This has several effects on tools that use elf / dwarf. I discovered that
debug tools that use elf/dwarf have the same problem and results in
in-compatibility between tools that generate elf/dwarf and those that
use these files.

2) Extensions to the elf/dwarf files to represent ISA or data types
specific issues have been a problem. Integer types are well handled
fixed point formats not so much.

elf/dwarf is surprisingly complex in ways that primarily designed
to save file space not as much of a goal in today's computing environment.

Keep detailed implementation notes on choices made to resolve
details, one thing that I didn't do but should have done. I resolved
issues on my initial implementation to make the intended debug tools
and the elf/dwarf files I was generating compatible but that in
the long term came back to bite me when I started to work on a
new tool set.

Walter..

[toc] | [prev] | [next] | [standalone]


#1457

FromCharles Chester <cc.63dw@gmail.com>
Date2014-12-30 18:18 -0500
Message-ID<14-12-014@comp.compilers>
In reply to#1451
On 12/29/14 08:05, Walter Banks wrote (in part, responding to John Levine):
> This isn't going to help much. I have plenty of coding scars to show for
> re-implementing compiler elf/dwarf support from scratch. Most of
> what I found comes from a number of issues.
>
> 1) Lack of comprehensive elf/dwarf documentation.

> 2) Extensions to the elf/dwarf files to represent ISA or data types
> specific issues have been a problem.

Well, now I know why I never received an answer to my request (from last
year) for a gentle introduction on adding dwarf support to a compiler --
there appears to be no such document.

C.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.compilers


csiph-web