Hi,
dwarflint (from the dwarf branch) gives the following error:
error: .debug_abbrev: abbr. attribute 0x2a: data_member_location with invalid form "sdata".
But that is actually valid. The Dwarf spec says that DW_AT_data_member_location may be either a constant, exprloc or loclistptr. If it is a constant then it should be interpreted as the offset into the struct.
The following patch fixes it. Does that make sense to commit to the dwarf branch?
Thanks,
Mark
Hi Petr,
On Sat, 2010-07-17 at 20:36 +0200, Petr Machata wrote:
16.07.2010 11:20, Mark Wielaard wrote:
dwarflint (from the dwarf branch) gives the following error:
Hi, dwarflint on the dwarf branch is not up to date. The one that is is on pmachata/dwarflint. That branch should have this fix.
Thanks. That branch does indeed not give an error for that case.
I did find a bug in CU address size checking that is only exposed on 32bit files. read_address_size is called with the wrong arguments (see attached). It might make sense to include some -m32 testcases on 64bit architectures.
BTW. There are some fixes missing from the origin/dwarf branch that help with building on newer systems (in particular commit b337b1). Also note that on the branch srcdir == builddir builds are broken since src/dwarflint is a directory (so the executable cannot be placed there).
Cheers,
Mark
It might make sense to include some -m32 testcases on 64bit architectures.
Where we have "proper" test cases, i.e. small focused regression test cases, we have exact test binaries stored (tests/testfile*.bz2). So for any known problem where it's feasible to gin up a trivial test file, we just store examples of all widths and bytesexes and all hosts will test all cross variants.
BTW. There are some fixes missing from the origin/dwarf branch that help with building on newer systems (in particular commit b337b1).
Unfortunately, the pmachata/dwarflint branch has some cruft in its tree that is confined to dwarflint. Until that is removed so the branch only touches dwarflint itself, we won't be able to merge it. This is why it's important to be disciplined in our use of topic branches. Always fork a branch freshly from the trunk, or freshly from the main dwarf branch, and only work on one thing in each branch.
Also note that on the branch srcdir == builddir builds are broken since src/dwarflint is a directory (so the executable cannot be placed there).
For a single program with many source files, it might be just as good to make it a top-level subdirectory rather than a subdirectory of src/. Uli is more likely to have an opinion about that than I am.
Thanks, Roland
20.07.2010 02:11, Roland McGrath wrote:
BTW. There are some fixes missing from the origin/dwarf branch that help with building on newer systems (in particular commit b337b1).
Thanks for the patch, it's now on the dwarflint branch.
Unfortunately, the pmachata/dwarflint branch has some cruft in its tree that is confined to dwarflint. Until that is removed so the branch only touches dwarflint itself, we won't be able to merge it.
Some of that cruft was there because of the merge with writer that I don't remember anymore why I had done. I cleaned everything up and merged the dwarf branch in. The dwarflint branch now only touches dwarflint plus there is one related update to dwarfstrings.c/h.
Also note that on the branch srcdir == builddir builds are broken since src/dwarflint is a directory (so the executable cannot be placed there).
For a single program with many source files, it might be just as good to make it a top-level subdirectory rather than a subdirectory of src/. Uli is more likely to have an opinion about that than I am.
I made it so.
PM
Some of that cruft was there because of the merge with writer that I don't remember anymore why I had done. I cleaned everything up and merged the dwarf branch in. The dwarflint branch now only touches dwarflint plus there is one related update to dwarfstrings.c/h.
Ok. But now that branch brings in the history of the wrong branch and then deleting that stuff, right? I'm not sure I like that at all.
If every commit touched either dwarflint stuff only or writer stuff only, then I think we can fairly easily tease it back apart. e.g., do "git rebase -i dwarf" and then drop all the commits that are for writer stuff rather than dwarflint stuff.
From doing "git log --stat origin/dwarf..origin/pmachata/dwarflint"
it looks off hand like they are all separate.
Thanks, Roland
17.08.2010 21:33, Roland McGrath wrote:
Some of that cruft was there because of the merge with writer that I don't remember anymore why I had done. I cleaned everything up and merged the dwarf branch in. The dwarflint branch now only touches dwarflint plus there is one related update to dwarfstrings.c/h.
Ok. But now that branch brings in the history of the wrong branch and then deleting that stuff, right? I'm not sure I like that at all.
Yeah, like that.
If every commit touched either dwarflint stuff only or writer stuff only, then I think we can fairly easily tease it back apart. e.g., do "git rebase -i dwarf" and then drop all the commits that are for writer stuff rather than dwarflint stuff.
From doing "git log --stat origin/dwarf..origin/pmachata/dwarflint" it looks off hand like they are all separate.
It wasn't, a couple commits touched both this and that. But I rebased it all relatively painlessly, most commits were clean. The current pmachata/dwarflint is a clean fork off dwarf, the original branch was deleted and replaced with the new one.
I pushed what used to be the old branch to pmachata/dwarflint-old, where I'll keep it a week or so in case I forgot about something.
PW
It wasn't, a couple commits touched both this and that. But I rebased it all relatively painlessly, most commits were clean. The current pmachata/dwarflint is a clean fork off dwarf, the original branch was deleted and replaced with the new one.
Great! Thanks very much for catering to my anal tendencies. I've merged that into dwarf now.
There has been a fair bit of interest in using dwarflint (well, at least one gcc person and one gdb person asked me about it).
Could you make sure there is a wiki page up to date that enumerates readably the things dwarflint checks for now, and the to-do list of new checks, and post the link here?
Thanks, Roland
On Wed, 2010-08-18 at 10:30 -0700, Roland McGrath wrote:
It wasn't, a couple commits touched both this and that. But I rebased it all relatively painlessly, most commits were clean. The current pmachata/dwarflint is a clean fork off dwarf, the original branch was deleted and replaced with the new one.
Great! Thanks very much for catering to my anal tendencies. I've merged that into dwarf now.
Is this the dwarf branch where future dwarflint work will go? I pushed a small change for tests/run-dwarflint-self.sh to use the new location (all tests PASS). Should that also go to some other branch now?
Running make check on the branch is a little painful though. I am using the attached cheat to get through it. And then it still takes 30 minutes on my machine. Time to really get to the bottom of why dwarfcmp and especially dwarfcmp-test -T is so incredibly slow.
Cheers,
Mark
Is this the dwarf branch where future dwarflint work will go? I pushed a small change for tests/run-dwarflint-self.sh to use the new location (all tests PASS). Should that also go to some other branch now?
Petr may maintain his own branches for work he isn't sure is ready to merge yet. But he has a free hand to push direclty to dwarf for any changes confined entirely to dwarflint code and that don't regress on make check.
Running make check on the branch is a little painful though. I am using the attached cheat to get through it. And then it still takes 30 minutes on my machine. Time to really get to the bottom of why dwarfcmp and especially dwarfcmp-test -T is so incredibly slow.
I've drafted a fine Dutch hacker to help with that.
Thanks, Roland
elfutils-devel@lists.fedorahosted.org