Re: PATCH: Fix linkonce support with debug

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

On Sun, Jun 15, 2003 at 03:07:19PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 14, 2003 at 09:48:26PM -0700, H. J. Lu wrote:
> > 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.
> 
> For those without interdiff handy, the change HJ made was to only
> convert the relocations to the kept section if the discarded and kept
> sections had the same size.
> 
> Um... I can't think offhand of any way to break it in C++ that doesn't
> also violate the ODR.  I think it's a bit too magic to do, but if it
> works...

I will check it in shortly.

> 
> Really we should be discarding this data instead of piling more hacks
> on it.
> 

No argument here.



H.J.