This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: debug flags (-feliminate-dwarf2-dups)
- To: Benjamin Kosnik <bkoz at redhat dot com>, jason at redhat dot com
- Subject: Re: debug flags (-feliminate-dwarf2-dups)
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 27 Mar 2001 23:37:28 -0500
- Cc: libstdc++ at gcc dot gnu dot org, snyder at fnal dot gov
- References: <Pine.SOL.3.91.1010327193444.23343D-100000@cse.cygnus.com>
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."