PATCH: Fix linkonce support with debug

[Daniel Jacobowitz]

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...

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer