Re: PATCH: Fix linkonce support with debug

["H. J. Lu" <hjl at lucon dot org>]

On Sat, Jun 14, 2003 at 05:54:50PM -0400, Daniel Jacobowitz wrote:
> On Fri, Jun 13, 2003 at 11:27:00AM -0700, H. J. Lu wrote:
> > On Fri, Jun 13, 2003 at 01:58:02PM -0400, Daniel Jacobowitz wrote:
> > > > > > This patch seems to work for me. We should try to preserve debug
> > > > > > information discarded by linkonce as much as we can. It may not be
> > > > > > ideal. But it is better than the current one.
> > > > > 
> > > > > No, I believe it is worse.
> > > > > 
> > > > > Consider that you now have multiple sections in .debug_info covering
> > > > > the same PC range - not necessarily all identical.
> > > > 
> > > > That is why I said it was not ideal.
> > > > >
> > > > > Also consider what happens if the multiple copies of the linkonce
> > > > > function are compiled with (say) different optimization levels.  You
> > > > > will have added a lot of line information which is completely bogus.
> > > > > 
> > > > 
> > > > Isn't is completely bogus in this situation today? We are picking
> > > 
> > > Here at least the bad line number information gets thrown down at PC 0. 
> > > It's still bogus, but on most systems less likely to get in the way.
> > > 
> > > > one from 2 bad choices. I don't think mine is any worse than the
> > > > current one.
> > > 
> > > I think it's worse.  It definitely isn't any better.
> > > 
> > 
> > There is a testcase which my patch fixes. Do you have a testcase which
> > works without my patch and doesn't work with my patch?
> 
> Sure.  It was easy to construct one from my previous explanation.  This
> exploits one of the possible problems: Support that a function without
> line information is placed right after the linkonce section, and
> suppose that the copy we keep was built with -O2 -g (like libstdc++
> often is) and the copy we discarded was built with -O0 -g (like my
> development code often is).  The line number information for the larger
> copy will appear to take control of the function without debug
> information, causing GDB's prologue analyzer to place a breakpoint in
> the completely wrong location.

If it is the only problem, this new patch seems to work OK.


H.J.

Attachment: binutils-linkonce.patch
Description: Text document