This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [BUG] Regression in 2.14.90 (relative to 2.13.90)


On Thu, Nov 13, 2003 at 11:12:40PM +0100, Carlo Wood wrote:
> On Wed, Nov 12, 2003 at 10:20:17AM -0800, H. J. Lu wrote:
> > > The change is intentional. The testcase looks normal to me since
> > > the discarded function is identical to the remained. Is there a
> > > problem with gdb? Please follow
> > > 
> > > http://sources.redhat.com/ml/binutils/2003-06/msg00471.html
> 
> I fail to understand how .eh_frame is related to this .debug_info
> problem.

I don't believe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7671

mentioned in

http://sources.redhat.com/ml/binutils/2003-06/msg00471.html

has anything to do with .eh_frame.

> 
> 
> But Jason Merrill says
> http://gcc.gnu.org/ml/gcc/2003-10/msg00682.html
> 
> "I don't see why there would be a problem with the current
> situation; only the right .debug_line info should match the current PC."
> 
> and in http://gcc.gnu.org/ml/gcc/2003-10/msg00689.html
> 
> "... the relocs in the .debug_line info for the discarded copy should
> resolve to 0.  That's how we deal with duplicate .debug_info ..."

It is a problem since gdb may pick up the wrong .debug_line info
with PC == 0 if it sees it first. Maybe gdb should ignore .debug_line
info with PC == 0.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]