Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1448 > unrolled thread
| Started by | "John R. Levine" <johnl@iecc.com> |
|---|---|
| First post | 2014-12-29 00:42 -0500 |
| Last post | 2014-12-30 18:18 -0500 |
| Articles | 5 — 5 participants |
Back to article view | Back to comp.compilers
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
| From | "John R. Levine" <johnl@iecc.com> |
|---|---|
| Date | 2014-12-29 00:42 -0500 |
| Subject | ELF 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]
| From | C Bergström <cbergstrom@pathscale.com> |
|---|---|
| Date | 2014-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]
| From | Hans Aberg <haberg-news@telia.com> |
|---|---|
| Date | 2014-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]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-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]
| From | Charles Chester <cc.63dw@gmail.com> |
|---|---|
| Date | 2014-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