This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: debug flags (-feliminate-dwarf2-dups)


Benjamin Kosnik <bkoz@redhat.com> writes:

Actually, I just noticed (while making sure the changes still worked
witht he current gdb/gcc, since i haven't touched it in a while) a bug
in -feliminate-dwarf2-dups that will  prevent it from working, even with the patch.

It's not putting the right die offset in some cases.

For instance, it puts it at relative address <383> when it's really in
a different compilation unit at offset 383 (IE it's putting a relative
offset for something not in the same comp_unit, rather than the
global die offset).

Jason, I believe this is why i had that test you removed (IIRC) that walked
up to the compile unit we had this die under, and make sure it matched
up with the comp unit of the thing we were gonna say it's relative to.

This only seems to happen if we are putting something relative to a
compilation unit ahead of it, not behind it.

Compile both of the files below with -feliminate-dwarf2-dups, and link
them. Then look at where it thinks _Alloc's type die is. It says 383
(0x17f in readelf, dwarfdump prints non-hex). It's really at offset
383 of the comp unit at 158472, (0x26c87 in readelf).

Thus, it needs to be absolute, not relative, and we need the right
offset, to boot.

Once that's fixed, and i reverify that everything works again, i'll post it to the
website.

----------test2.cpp-------------
#include <string>
#include <list>

----------test1.cpp-------------
#include <string>
#include <list>
#include <map>
#include <set>
#include <vector>
#include <algorithm>

std::map<std::string, std::map<std::vector<int>, std::set<std::list<int> > > > foo;
int main(void)
{
}




> Again... Please either post a tarball of your sources, a binary, or 
> refrain from teasing us. Talking about doing all this stuff and then not 
> letting anybody use them or verify your work is, IMHO, quite lame.
> 
> -benjamin
> 
> > No, it's just that gdb can't debug things with -feliminate-dwarf2-dups
> > on yet.
> > I basically had to rewrite large portions of the dwarf2 reader because it makes
> > stupid assumptions (though i can't fault this, because it's based on
> > the dwarf1 reader, where these assumptions are valid), and I don't
> > want the hassle of trying to get the  patch approved, because it
> > basically, well, rewrites the dwarf2 reader, making it a pain in the
> > ass to get approved.
> > If someone else wants to herd it through the gdb patch approval
> > process, i'll happily send it along.

-- 
I was going to tape some records onto a cassette, but I got the
wires backwards.  I erased all of the records.  When I returned
them to my friend, he said, "Hey, these records are all blank."


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]