This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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: 8-byte register values on a 32-bit machine


On Wed, Mar 12, 2003 at 10:35:15AM -0500, Andrew Cagney wrote:
> >Okay, I got some sleep and drank some tea and stuff.  I'm a bit more
> >calm now.  :)
> >
> >I filed a proper PR, so that Daniel J (or anybody) can flow it into
> >their TODO list.  Daniel said he has several things to do in this code
> >so I want to get in line properly.
> >
> >I did mark it severity=critical because gdb prints incorrect values, and
> >priority=high because Stephane C says that it happens a lot on the HC11.
> >
> >gdb 5.3 has a different bug in the same area, so this is only sort-of a
> >regression.  The specific program store.exp in the test suite regressed
> >between 2003-02-15 and 2003-02-23, but my test program r8.c in the PR is
> >busted with both gdb 5.3 and gdb 2003-03-01-cvs.
> 
> Shouldn't the new code have been made conditional until it at least 
> equalled the functionality of the old mechanism?
> 
> By failing to do this to do this, the next release of GDB has gained a 
> dependency on the timetable of an internal change.  That is bad.

The new code fixes some reported wrong-value-reported bugs in other debugging
situations; one of them was reported just recently.  So I don't think
'equalled the functionality of the old mechanism' is really quite fair.

I was also not aware that we had sketchy multi-register support until
it was pointed out to me, because the support isn't in any of the
places I was working in directly; it's off in the generic value code,
isn't it?  So I didn't know this was going to happen.  We have a plan
to fix it, too.  Mark posted it, and then ran out of time (?).  You
didn't like his plan because:

   I think it is very dangerous.  It's assuming a specific algorithm
   in the compiler.  That locks both GDB and GCC into something of a
   death spiral.  I think its far better to try and get a proper
   location mechanism working.

Well, that's what we did before, in the "old mechanism", and we don't
have any new debug info that we didn't have then so it's what we need
to keep doing until support for the new debug info is ready (then GCC
can emit it more broadly).

By the way, you wrote:
On Sun, Feb 02, 2003 at 11:14:29AM -0500, Andrew Cagney wrote:
> If only it were that easy.  The dwarf2 reader, for instance, also 
> contains the assumption that registers are allocated sequentially.
> 
> Is the proposal to modify such readers so that they check against this 
> next_allocated_regnum algorithm?

And I wrote back:
> Where?  I can't find this; it doesn't even acknowledge multi-register
> values.

I still don't understand what code you're referring to in the reader.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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