Petr Sorfa's Dwarf 2 changes

Petr Sorfa's Dwarf 2 changes

[Jim Blandy]

John, could you post a copy of your current dwarf2read.c, with all
your changes --- approved, unapproved, and unsubmitted --- in place?

I'm undertaking some related work in dwarf2read.c which will almost
certainly conflict with Caldera's changes, and I'd like to see where
you guys ended up.

Re: Petr Sorfa's Dwarf 2 changes

[Andrew Cagney]

> John, could you post a copy of your current dwarf2read.c, with all
> your changes --- approved, unapproved, and unsubmitted --- in place?

(John, I take it jim just wants you to send the entire file as currently 
is in private.  Jim, the caldera code is in 
ftp://sources.redhat.com/pub/gdb/contrib/caldera/ (i think)).

> I'm undertaking some related work in dwarf2read.c which will almost
> certainly conflict with Caldera's changes, and I'd like to see where
> you guys ended up.

Care to expand?

Andrew

Re: Petr Sorfa's Dwarf 2 changes

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> > I'm undertaking some related work in dwarf2read.c which will almost
> > certainly conflict with Caldera's changes, and I'd like to see where
> > you guys ended up.
> 
> Care to expand?

Sure --- I'm trying to put together a patch to support
inter-compilation unit die references, which is (the hardest?) part of
supporting Dwarf 2 compression.

I think the changes are going to be pretty widespread.

At the moment, dwarf2read.c has a number of global variables that
describe per-compilation-unit things.  These get set as we do the
psymtab scan, stashed in each psymtab we create, and then restored
each time we convert a psymtab to a symtab.  If we're going to handle
inter-CU references, we're going to be dealing with more than one CU
at a time, so that's not going to be sufficient any more --- which CU
you need depends on which die you're looking at.

I'd like to change GDB to have a per-objfile Dwarf-specific structure
(like struct dbx_symfile_info for STABS), and per-CU Dwarf-specific
structures.  These would be passed as arguments amongst the
dwarf2read.c functions as appropriate.  Furthermore, each die might
need to have a pointer to the CU that owns it.

Those are pretty pervasive changes, but I think the folks who have
worked in dwarf2read.c will agree that they're the right way to go.
When I've gotten something working on the branch I'll have more
perspective on what's really needed.

Re: Petr Sorfa's Dwarf 2 changes

[Daniel Jacobowitz]

On Mon, Nov 04, 2002 at 03:06:21PM -0500, Jim Blandy wrote:
> 
> Andrew Cagney <ac131313@redhat.com> writes:
> > > I'm undertaking some related work in dwarf2read.c which will almost
> > > certainly conflict with Caldera's changes, and I'd like to see where
> > > you guys ended up.
> > 
> > Care to expand?
> 
> Sure --- I'm trying to put together a patch to support
> inter-compilation unit die references, which is (the hardest?) part of
> supporting Dwarf 2 compression.
> 
> I think the changes are going to be pretty widespread.
> 
> At the moment, dwarf2read.c has a number of global variables that
> describe per-compilation-unit things.  These get set as we do the
> psymtab scan, stashed in each psymtab we create, and then restored
> each time we convert a psymtab to a symtab.  If we're going to handle
> inter-CU references, we're going to be dealing with more than one CU
> at a time, so that's not going to be sufficient any more --- which CU
> you need depends on which die you're looking at.
> 
> I'd like to change GDB to have a per-objfile Dwarf-specific structure
> (like struct dbx_symfile_info for STABS), and per-CU Dwarf-specific
> structures.  These would be passed as arguments amongst the
> dwarf2read.c functions as appropriate.  Furthermore, each die might
> need to have a pointer to the CU that owns it.
> 
> Those are pretty pervasive changes, but I think the folks who have
> worked in dwarf2read.c will agree that they're the right way to go.
> When I've gotten something working on the branch I'll have more
> perspective on what's really needed.

Not only will they agree, I believe Petr and John had already finished
doing this.  Doubtless there's still some room for improvement, but the
functionality is there...  John, do you have that merged dwarf2read
available?

[For instance, from Petr's July posting:
        * dwarf2read.c (build_die_ref): New function that builds
          a new die reference if necessary, will search across
          multiple comp units to find the reference.
          (find_die_ref): New function that searches for a die
          reference for a given comp unit.
          (find_cu_header_from_begin_offset): New function that
          searches through a link list of comp unit headers for
          a comp unit that matches the given offset.
 ]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Petr Sorfa's Dwarf 2 changes

[Daniel Berlin]

> Not only will they agree, I believe Petr and John had already finished
> doing this.

>
And I did it before them.
>  Doubtless there's still some room for improvement, but the
> functionality is there...  John, do you have that merged dwarf2read
> available?
If they don't, you should be able to find mine in the archives.
Unless i'm misremembering Petr's, it keeps all the CU's around all the 
time.
One thing I did was to make it so you could throw away CU's at will, 
and it would just reread them if/when necessary (IE it would just keep 
the last 10 used CU's or something as a cache).   Cuts down on memory 
usage significantly with almost no loss in speed.

PS I remember someone mentioning something about not needing to 
basically rewrite the dwarf2 reader to do this, though, which is what 
"pretty pervasive changes" sounds like. Not that i'm bitter, i just 
find it funny. :)
Though i'm aware the retort will be that i did more than necessary 
(like mmapping the symbol files, and the ever controversial duplicate 
removal).

Jim, you should be able to just rip the pieces from the dwarf2 reader 
rewrite i had done, or Petr did, without any trouble.
> [For instance, from Petr's July posting:
>         * dwarf2read.c (build_die_ref): New function that builds
>           a new die reference if necessary, will search across
>           multiple comp units to find the reference.
>           (find_die_ref): New function that searches for a die
>           reference for a given comp unit.
>           (find_cu_header_from_begin_offset): New function that
>           searches through a link list of comp unit headers for
>           a comp unit that matches the given offset.
>  ]
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: Petr Sorfa's Dwarf 2 changes

[Daniel Jacobowitz]

On Mon, Nov 04, 2002 at 03:38:05PM -0500, Daniel Berlin wrote:
> >Not only will they agree, I believe Petr and John had already finished
> >doing this.
> 
> >
> And I did it before them.

Yes, sorry.  I still have code from you, posted to gdb-patches in July
2001, which does this.  I merged it most of the way forward to CVS a
couple of months later and ran out of time to finish the job.

> > Doubtless there's still some room for improvement, but the
> >functionality is there...  John, do you have that merged dwarf2read
> >available?
> If they don't, you should be able to find mine in the archives.
> Unless i'm misremembering Petr's, it keeps all the CU's around all the 
> time.
> One thing I did was to make it so you could throw away CU's at will, 
> and it would just reread them if/when necessary (IE it would just keep 
> the last 10 used CU's or something as a cache).   Cuts down on memory 
> usage significantly with almost no loss in speed.

Exactly what I was trying to remember :)


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Petr Sorfa's Dwarf 2 changes

[Jim Blandy]

Daniel Berlin <dberlin@dberlin.org> writes:
> PS I remember someone mentioning something about not needing to
> basically rewrite the dwarf2 reader to do this, though, which is what
> "pretty pervasive changes" sounds like. Not that i'm bitter, i just
> find it funny. :)

Well, by "pervasive" I mean, "this will probably conflict with other
patches."  You'll still recognize all the functions.

> Jim, you should be able to just rip the pieces from the dwarf2 reader
> rewrite i had done, or Petr did, without any trouble.

Yep, that's the plan.

Re: Petr Sorfa's Dwarf 2 changes

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Nov 04, 2002 at 03:06:21PM -0500, Jim Blandy wrote:
> > 
> > Andrew Cagney <ac131313@redhat.com> writes:
> > > > I'm undertaking some related work in dwarf2read.c which will almost
> > > > certainly conflict with Caldera's changes, and I'd like to see where
> > > > you guys ended up.
> > > 
> > > Care to expand?
> > 
> > Sure --- I'm trying to put together a patch to support
> > inter-compilation unit die references, which is (the hardest?) part of
> > supporting Dwarf 2 compression.
> > 
> > I think the changes are going to be pretty widespread.
> > 
> > At the moment, dwarf2read.c has a number of global variables that
> > describe per-compilation-unit things.  These get set as we do the
> > psymtab scan, stashed in each psymtab we create, and then restored
> > each time we convert a psymtab to a symtab.  If we're going to handle
> > inter-CU references, we're going to be dealing with more than one CU
> > at a time, so that's not going to be sufficient any more --- which CU
> > you need depends on which die you're looking at.
> > 
> > I'd like to change GDB to have a per-objfile Dwarf-specific structure
> > (like struct dbx_symfile_info for STABS), and per-CU Dwarf-specific
> > structures.  These would be passed as arguments amongst the
> > dwarf2read.c functions as appropriate.  Furthermore, each die might
> > need to have a pointer to the CU that owns it.
> > 
> > Those are pretty pervasive changes, but I think the folks who have
> > worked in dwarf2read.c will agree that they're the right way to go.
> > When I've gotten something working on the branch I'll have more
> > perspective on what's really needed.
> 
> Not only will they agree, I believe Petr and John had already finished
> doing this.  Doubtless there's still some room for improvement, but the
> functionality is there...  John, do you have that merged dwarf2read
> available?

Yeah, not to diss that at all: I should have also explained that I'm
hoping to steal as much of that work as I can.  (Thus the request that
started this thread.)

Re: Petr Sorfa's Dwarf 2 changes

[John Wolfe]

> From jimb@zenia.red-bean.com Wed Oct 23 13:53:43 2002

> John, could you post a copy of your current dwarf2read.c, with all
> your changes --- approved, unapproved, and unsubmitted --- in place?
> 
> I'm undertaking some related work in dwarf2read.c which will almost
> certainly conflict with Caldera's changes, and I'd like to see where
> you guys ended up.

Arrrgh, just resynching with the top-of tree.  I was incorporating Petr's
original patch 

   http://sources.redhat.com/ml/gdb-patches/2002-07/msg00066.html
   
in 3 distinct steps, so that what I submitted at any step would/could
stand-alone.  There were some struct member name changes and I noticed
that the new lookup routines did not consider multiple .dwarf_info
sections (shared object), so I am revising them.

I will have the full patch incorporated and retested by Friday noon.
Will that be sufficient?

Re: Petr Sorfa's Dwarf 2 changes

[John Wolfe]

> From: Daniel Jacobowitz <drow@mvista.com>
> To: Jim Blandy <jimb@redhat.com>, John Wolfe <jlw@caldera.com>
> Cc: Andrew Cagney <ac131313@redhat.com>, gdb@sources.redhat.com
> Subject: Re: Petr Sorfa's Dwarf 2 changes
> Message-ID: <20021104202641.GA7194@nevyn.them.org>
> Mail-Followup-To: Jim Blandy <jimb@redhat.com>,
	John Wolfe <jlw@caldera.com>, Andrew Cagney <ac131313@redhat.com>,
	gdb@sources.redhat.com
> References: <200210231720.g9NHKqO32140@zenia.red-bean.com> 
<3DB6EEE6.1060100@redhat.com> <vt2fzuhje0y.fsf@zenia.red-bean.com>
> Content-Disposition: inline
> In-Reply-To: <vt2fzuhje0y.fsf@zenia.red-bean.com>
> User-Agent: Mutt/1.5.1i
> Status: RO
> X-SCO-PAD: XXXXXX
> X-SCO-UID: 80086
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-MD5: DO4ydt8CLpx+WpEXXcY7yw==
> Content-Length: 2412
> 
> On Mon, Nov 04, 2002 at 03:06:21PM -0500, Jim Blandy wrote:
> > 
> > Andrew Cagney <ac131313@redhat.com> writes:
> > > > I'm undertaking some related work in dwarf2read.c which will almost
> > > > certainly conflict with Caldera's changes, and I'd like to see where
> > > > you guys ended up.
> > > 
> > > Care to expand?
> > 
> > Sure --- I'm trying to put together a patch to support
> > inter-compilation unit die references, which is (the hardest?) part of
> > supporting Dwarf 2 compression.
> > 
> > I think the changes are going to be pretty widespread.
> > 
> > At the moment, dwarf2read.c has a number of global variables that
> > describe per-compilation-unit things.  These get set as we do the
> > psymtab scan, stashed in each psymtab we create, and then restored
> > each time we convert a psymtab to a symtab.  If we're going to handle
> > inter-CU references, we're going to be dealing with more than one CU
> > at a time, so that's not going to be sufficient any more --- which CU
> > you need depends on which die you're looking at.
> > 
> > I'd like to change GDB to have a per-objfile Dwarf-specific structure
> > (like struct dbx_symfile_info for STABS), and per-CU Dwarf-specific
> > structures.  These would be passed as arguments amongst the
> > dwarf2read.c functions as appropriate.  Furthermore, each die might
> > need to have a pointer to the CU that owns it.
> > 
> > Those are pretty pervasive changes, but I think the folks who have
> > worked in dwarf2read.c will agree that they're the right way to go.
> > When I've gotten something working on the branch I'll have more
> > perspective on what's really needed.
> 
> Not only will they agree, I believe Petr and John had already finished
> doing this.  Doubtless there's still some room for improvement, but the
> functionality is there...  John, do you have that merged dwarf2read
> available?
> 
> [For instance, from Petr's July posting:
>         * dwarf2read.c (build_die_ref): New function that builds
>           a new die reference if necessary, will search across
>           multiple comp units to find the reference.
>           (find_die_ref): New function that searches for a die
>           reference for a given comp unit.
>           (find_cu_header_from_begin_offset): New function that
>           searches through a link list of comp unit headers for
>           a comp unit that matches the given offset.
>  ]

Apologies for the delay in responding.  I actually took a couple of days
off.

Yes, I do.  I sent a full  copy of dwarf2read.c directly to Jim with a
copy to gdb@sources.redhat.com.  Jim got his copy, but the copy to 
gdb@sources.redhat.com was bounced to to an e-mail size limit.

The key thing is that Jim got the copy to look at.