Re: 8-byte register values on a 32-bit machine

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

mec> The general case of 2-word structures in 5.3 was broken.  That is to say,
mec> my simple test program (attached to the PR) fails with both 5.3 and HEAD.

ac> I386 or general?  To the best of my knowledge, structs worked on 
ac> non-i386 architectures.

Native i686-pc-linux-gnu.

I just tested on native sparc-sun-solaris2.7, but the only compiler
I have, gcc 3.2.2, does not put the 2-word structure into registers.

Michael C

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

> mec> The general case of 2-word structures in 5.3 was broken.  That is to say,
> mec> my simple test program (attached to the PR) fails with both 5.3 and HEAD.
> 
> ac> I386 or general?  To the best of my knowledge, structs worked on 
> ac> non-i386 architectures.
> 
> Native i686-pc-linux-gnu.

Right, so it can't be assumed that `the general case of 2-word structs 
in 5.3 was broken'.

> I just tested on native sparc-sun-solaris2.7, but the only compiler
> I have, gcc 3.2.2, does not put the 2-word structure into registers.

Thanks for clarifying this,
Andrew

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

andrew> Right, so it can't be assumed that `the general case of
andrew> 2-word structs in 5.3 was broken'.

It can't be assumed that they worked in 5.3, either.

In gdb HEAD, last time I looked, the dwarf2 code fetched only one word
from the target.  So with gdb HEAD I believe they are broken on ALL
architectures, unless Daniel has fixed them in the past week.

Michael C

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

> 
> I don't know if it would break or not.
> 
> 
>> If that's not the current proposal, could you reword it to help
>> eliminate the confusion over what you intend?
> 
> 
> No one is proposing to leave it broken.  To pull up an example from
> earlier in the thread, Andrew broke x86-64 when working on the frame
> changes.  It was an accident, and eventually fixed (by Michal Ludvig, I
> might add).  I apparently broke long long (in registers) in some of my
> DWARF-2 support patches.  I'm working to fix it.  I'm only one person
> and I only have so much time.

For this `long long' case, can a simple local tweak that restores 
existing behavior (while the new code is finished / tested).  That way 
the pressure is off you to get this stuff finished quickly instead of 
cleanly.

Andrew

PS: Frames vs MIPS is a better example.

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

> The general case of 2-word structures in 5.3 was broken.  That is to say,
> my simple test program (attached to the PR) fails with both 5.3 and HEAD.

I386 or general?  To the best of my knowledge, structs worked on 
non-i386 architectures.

Andrew

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Wed, Mar 12, 2003 at 02:40:40PM -0500, Andrew Cagney wrote:
> >
> >I don't know if it would break or not.
> >
> >
> >>If that's not the current proposal, could you reword it to help
> >>eliminate the confusion over what you intend?
> >
> >
> >No one is proposing to leave it broken.  To pull up an example from
> >earlier in the thread, Andrew broke x86-64 when working on the frame
> >changes.  It was an accident, and eventually fixed (by Michal Ludvig, I
> >might add).  I apparently broke long long (in registers) in some of my
> >DWARF-2 support patches.  I'm working to fix it.  I'm only one person
> >and I only have so much time.
> 
> For this `long long' case, can a simple local tweak that restores 
> existing behavior (while the new code is finished / tested).  That way 
> the pressure is off you to get this stuff finished quickly instead of 
> cleanly.

Except that I don't think such a local tweak is possible in this case.
I could be wrong.  Anyone's welcome to try, including the maintainers
of the code in question.

I'm working on the proper solution.  Hold your horses, people.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

The general case of 2-word structures in 5.3 was broken.  That is to say,
my simple test program (attached to the PR) fails with both 5.3 and HEAD.

I would like to re-suggest my idea that gdb simply print "<unknown>"
or something for all the words beyond the first word in a register
variable.  But I'll back whatever Daniel thinks is right.

Michael C

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Wed, Mar 12, 2003 at 02:47:57PM -0500, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  Daniel> On Wed, Mar 12, 2003 at 01:29:03PM -0500, Andrew Cagney
>  Daniel> wrote:
>  >> > >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.
>  >> 
>  >> True.  However, breaking `long long' is a serious regression.  If
>  >> a developer can't trust that, what can they trust?
> 
>  Daniel> Historically it hasn't been all that trustable anyway.  I
>  Daniel> don't have a testcase handy but CORE_ADDRs in GDB backtraces
>  Daniel> tend to be wrong, even when they're properly saved to the
>  Daniel> stack.  Et cetera.
> 
> I don't like the way this discussion is going.  Perhaps I'm reading
> too much into the words.  A quick review of the thread doesn't help
> make it clearer.
> 
> We have a large body of code full of long long variables, compiled for
> MIPS using the o32 ABI.  So each of those ends up in a register pair.
> 
> I'm not aware of any reported problems in dealing with long long
> variables on that platform.
> 
> So... if the current proposal has the side effect of breaking that
> working function, on the grounds that it "wasn't all that reliable",
> I've got to ask why that's a valid argument.

I don't know if it would break or not.

> If that's not the current proposal, could you reword it to help
> eliminate the confusion over what you intend?

No one is proposing to leave it broken.  To pull up an example from
earlier in the thread, Andrew broke x86-64 when working on the frame
changes.  It was an accident, and eventually fixed (by Michal Ludvig, I
might add).  I apparently broke long long (in registers) in some of my
DWARF-2 support patches.  I'm working to fix it.  I'm only one person
and I only have so much time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> On Wed, Mar 12, 2003 at 01:29:03PM -0500, Andrew Cagney
 Daniel> wrote:
 >> > >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.
 >> 
 >> True.  However, breaking `long long' is a serious regression.  If
 >> a developer can't trust that, what can they trust?

 Daniel> Historically it hasn't been all that trustable anyway.  I
 Daniel> don't have a testcase handy but CORE_ADDRs in GDB backtraces
 Daniel> tend to be wrong, even when they're properly saved to the
 Daniel> stack.  Et cetera.

I don't like the way this discussion is going.  Perhaps I'm reading
too much into the words.  A quick review of the thread doesn't help
make it clearer.

We have a large body of code full of long long variables, compiled for
MIPS using the o32 ABI.  So each of those ends up in a register pair.

I'm not aware of any reported problems in dealing with long long
variables on that platform.

So... if the current proposal has the side effect of breaking that
working function, on the grounds that it "wasn't all that reliable",
I've got to ask why that's a valid argument.

If that's not the current proposal, could you reword it to help
eliminate the confusion over what you intend?

Thanks,
	paul

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

> On Wed, Mar 12, 2003 at 01:29:03PM -0500, Andrew Cagney wrote:
> 
>> >
>> >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.
> 
>> 
>> True.  However, breaking `long long' is a serious regression.  If a 
>> developer can't trust that, what can they trust?
> 
> 
> Historically it hasn't been all that trustable anyway.  I don't have a
> testcase handy but CORE_ADDRs in GDB backtraces tend to be wrong, even
> when they're properly saved to the stack.  Et cetera.

On the i386.  The case that Mark identified.

Andrew

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Wed, Mar 12, 2003 at 01:29:03PM -0500, Andrew Cagney wrote:
> >
> >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.
> 
> True.  However, breaking `long long' is a serious regression.  If a 
> developer can't trust that, what can they trust?

Historically it hasn't been all that trustable anyway.  I don't have a
testcase handy but CORE_ADDRs in GDB backtraces tend to be wrong, even
when they're properly saved to the stack.  Et cetera.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

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

True.  However, breaking `long long' is a serious regression.  If a 
developer can't trust that, what can they trust?

Andrew

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

>> >   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.
> 
>> 
>> There are other ways forward on this - moving the algorithm to libiberty 
>> (like the demangler).
> 
> 
> This is a target-specific allocation order, for communication between
> GCC and GDB, not a matter of published interfaces - I don't think it
> belongs in libiberty.  It's subject to change, but I have a reasonable
> expectation that it won't change until after debugging info to express
> it is available.
> 
> In any case I'm going back to working on locations as objects, which is
> the next step in fixing this properly.

Mark's point was that the algorithm, while machine specific, hasn't 
changed in N (10?) years.

Even if in the future, the algorithm does change, GDB/GCC might as well 
share the code for the original one so that GDB can work better with 
older compilers.

Andrew

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Wed, Mar 12, 2003 at 11:57:49AM -0500, Andrew Cagney wrote:
> 
> >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.
> 
> There are other ways forward on this - moving the algorithm to libiberty 
> (like the demangler).

This is a target-specific allocation order, for communication between
GCC and GDB, not a matter of published interfaces - I don't think it
belongs in libiberty.  It's subject to change, but I have a reasonable
expectation that it won't change until after debugging info to express
it is available.

In any case I'm going back to working on locations as objects, which is
the next step in fixing this properly.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

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

There are other ways forward on this - moving the algorithm to libiberty 
(like the demangler).

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

As we've now re-discovered, the assumption is is there, its real, but it 
is implicit.
> 
> I still don't understand what code you're referring to in the reader.

Andrew

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

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

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

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

Andrew

Re: 8-byte register values on a 32-bit machine

[Keith Walker]

At 11:25 03/03/2003 +0000, Richard Earnshaw wrote:
> > On Sat, Mar 01, 2003 at 06:42:58PM -0500, Andrew Cagney wrote:
> >
> > By the way, assuming I can find the time (ugh) I'm not done with
> > LOC_COMPUTED yet.  On my list so far:
> >   - Location lists
> >   - Turning locations into better defined objects
> >   - Thus, allowing LOC_COMPUTED to return a non-computed "location"
> >   - Allowing more complex locations, namely DW_OP_piece style.
> >   - Eventually turning on more uses of DW_OP_piece in GCC.
>
>The main reason gcc allocates objects to contiguous register ranges is
>because gdb can't handle anything else.  Fixing gdb to allow location
>lists would be a major step forward, since then gcc would be able to split
>double-register objects before register allocation and allocate each part
>individually.  That could be a major win on register starved machines.

Actually it is the implementation of the DW_OP_piece operator (rather than 
location lists) which allows the location of an object to be split into 
multiple sub-locations.

Location lists allows, for any given PC value, for you to describe zero 
(optimized out) or more locations for an object.     These locations can 
then be broken down into sub-locations if the resulting expression 
evaluated then contains a DW_OP_piece operator.

Keith

Re: 8-byte register values on a 32-bit machine

[Richard Earnshaw]

> On Sat, Mar 01, 2003 at 06:42:58PM -0500, Andrew Cagney wrote:
> > Mark,
> > 
> > Now that there is this loc_computed stuff, it is probably possible to 
> > modify stabs to, for the case in question, implement a loc_computed symbol.
> 
> Hmm, I'm not sure that's the right way to go.  DWARF-2 also will say
> that an eight byte value is in one register.  Why put the hacks in
> both readers?
> 
> By the way, assuming I can find the time (ugh) I'm not done with
> LOC_COMPUTED yet.  On my list so far:
>   - Location lists
>   - Turning locations into better defined objects
>   - Thus, allowing LOC_COMPUTED to return a non-computed "location"
>   - Allowing more complex locations, namely DW_OP_piece style.
>   - Eventually turning on more uses of DW_OP_piece in GCC.

The main reason gcc allocates objects to contiguous register ranges is 
because gdb can't handle anything else.  Fixing gdb to allow location 
lists would be a major step forward, since then gcc would be able to split 
double-register objects before register allocation and allocate each part 
individually.  That could be a major win on register starved machines.

R.

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Sun, Mar 02, 2003 at 10:35:01AM +0100, Stephane Carrez wrote:
> Hi!
> 
> Michael Elizabeth Chastain wrote:
> 
> >[...]
> >Anyways, I think there are two problems here:
> >
> >(1) dwarf2_evaluate_loc_desc is getting called with ctx->in_reg=true
> >    and size=8.  I need to provide an actual test executable to show
> >    this happening.  When this happens, dwarf2_evaluate_loc_desc just
> >    reads *1* register.  This is definitely wrong (if my description
> >    of gdb's behavior is accurate).
> >
> 
> 
> clap! clap! clap!
> 
> FYI, I have this problem too with HC11 and it is *critical* for me as
> this platform being a 16-bit register target, it uses multiple registers
> quite intensively (up to 4 for long long).  It was working very very well 
> before...

OK, so we need to do something about this before the next release. 
It's a problem I hadn't anticipated.  I have several ideas on how to
progress, particularly:
  - Making a call to the LOC_COMPUTED functions return a LOC_REGISTER
so that the logic in read_var_value can go back to handling this case.
  - Implement the get-next-register mechanism that Mark K. designed.

Hmm, for the former I'm not sure I know what I want it to look like
yet; but some logic definitely needs to be pushed higher than it is
(i.e. out of the evaluator).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

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.

Michael C

Re: 8-byte register values on a 32-bit machine

[Stephane Carrez]

Hi!

Michael Elizabeth Chastain wrote:

> [...]
> Anyways, I think there are two problems here:
> 
> (1) dwarf2_evaluate_loc_desc is getting called with ctx->in_reg=true
>     and size=8.  I need to provide an actual test executable to show
>     this happening.  When this happens, dwarf2_evaluate_loc_desc just
>     reads *1* register.  This is definitely wrong (if my description
>     of gdb's behavior is accurate).
> 


clap! clap! clap!

FYI, I have this problem too with HC11 and it is *critical* for me as
this platform being a 16-bit register target, it uses multiple registers
quite intensively (up to 4 for long long).  It was working very very well before...

	Stephane


-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@nerim.fr                  Stephane.Carrez@solsoft.fr
WWW:    http://stcarrez.nerim.net          http://www.solsoft.com
         Free the Software!                 Visual Security Policy Management

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

mec> I understand that on some targets, gcc and gdb might agree on register
mec> number allocation (ignore for the moment that there are other compilers
mec> besides gcc).  Okay, for targets where we have a guarantee about that,
mec> then enable sequential register access.  But i686-pc-linux-gnu is
mec> definitely not such a target.

mark> I don't agree with the defenitely here.  GCC has been allocating the
mark> registers in a well determined order for at least 10 years now.

Ah, yeah, I am saying that gcc and gdb disagree on the register
number ordering, and you are saying that gcc has a well determined
order -- so in principle gdb could know that order and follow it.
I think both statements are true.

This test worked for months and then regressed recently.  gdb's code
recently changed from "iterate over some registers" (which worked for
this test case, at least, but is not guaranteed to work all the time).
Then this patch happened:

  2003-02-21  Daniel Jacobowitz  <drow@mvista.com>

  Based on a patch from Daniel Berlin (dberlin@dberlin.org)
  ...
  * dwarf2expr.c, dwarf2expr.h, dwarf2loc.c, dwarf2loc.h: New files.
  ...

Before this patch, the dwarf2 reader would mark these as LOC_REGISTER
and value_from_register would loop over the # of registers that are
needed.  This is the case we are talking about, where gdb and the
compiler in use might or might not match on the register assignments.

After this patch, (that is, in today's gdb), the dwarf2 reader marks the
multi-register expression as LOC_COMPUTED.  Then
dwarf2_evaluate_loc_desc calls store_unsigned_integer just once, *no
matter how large the size is*.  I've seen this happen by debugging gdb
running on my test program (build testsuite/gdb.base/store.exp with gcc
2.95.3 -gdwarf-2).  gdb doesn't even try to read any other registers.
So if the location is "register %eax, size 8", gdb does not even look in
%edx.  I don't know exactly where gdb gets bytes 4-7 of the data.  I
%suspect it's just using uninitialized buffer contents.  That's what I
%really meant about gdb pulling values "out of its ass".

Also I apologize for that phrase.  I think it's accurate for what gdb is
doing right now with, but I didn't share that knowledge about
dwarf2_evaluate_loc_desc, and it's kind of inflammatory to say that for
register orders.  Plus it's disrespectful to the developers which is the
real problem.  Obviously this is work in progress and that's what CVS is
for, and that's what regression testing is for.

Anyways, I think there are two problems here:

(1) dwarf2_evaluate_loc_desc is getting called with ctx->in_reg=true
    and size=8.  I need to provide an actual test executable to show
    this happening.  When this happens, dwarf2_evaluate_loc_desc just
    reads *1* register.  This is definitely wrong (if my description
    of gdb's behavior is accurate).

(2) We have to decide what gdb will do in various cases.  As I've
    mentioned, I'm hostile to the idea of gdb intuiting the register
    order.  If there is no list of registers is not as long as the
    data size then I would rather that gdb print "<unknown>" for the
    unknown ones.  But I recognize that's up to the symtab
    maintainers to decide.  Thanks for listening to my input.

Michael C

Re: 8-byte register values on a 32-bit machine

[Daniel Jacobowitz]

On Sat, Mar 01, 2003 at 06:42:58PM -0500, Andrew Cagney wrote:
> Mark,
> 
> Now that there is this loc_computed stuff, it is probably possible to 
> modify stabs to, for the case in question, implement a loc_computed symbol.

Hmm, I'm not sure that's the right way to go.  DWARF-2 also will say
that an eight byte value is in one register.  Why put the hacks in
both readers?

By the way, assuming I can find the time (ugh) I'm not done with
LOC_COMPUTED yet.  On my list so far:
  - Location lists
  - Turning locations into better defined objects
  - Thus, allowing LOC_COMPUTED to return a non-computed "location"
  - Allowing more complex locations, namely DW_OP_piece style.
  - Eventually turning on more uses of DW_OP_piece in GCC.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

Mark,

Now that there is this loc_computed stuff, it is probably possible to 
modify stabs to, for the case in question, implement a loc_computed symbol.

Andrew

Re: 8-byte register values on a 32-bit machine

[Andrew Cagney]

> I think we've lost the stabs battle. So I started to look into the
> DWARF2 format, but could not find anything that helps. Does anybody know
> if this format supports this sort of situation?

Dwarf2 has the idea of a location expression.  It lets GCC specify 
something like:

	Reg %eax piece 4, Reg %ecx, piece 4

This is what is behind the dwarf2expr* et.al. changes.  I'd download a 
copy of the dwarf2 spec (see .../gdb/links/ but note that, right now the 
m/c might be down - I got an e-mail last night indicating a temp outage).

Andrew

Re: 8-byte register values on a 32-bit machine

[Mark Kettenis]

   Date: Sat, 1 Mar 2003 14:57:15 -0600
   From: Michael Elizabeth Chastain <mec@shout.net>

   The heinous part is that gdb *knows* it is pulling some register
   value out of its ass for p1.y.  I understand that on some targets,
   gcc and gdb might agree on register number allocation (ignore for
   the moment that there are other compilers besides gcc).  Okay, for
   targets where we have a guarantee about that, then enable
   sequential register access.  But i686-pc-linux-gnu is definitely
   not such a target.

I don't agree with the defenitely here.  GCC has been allocating the
registers in a well determined order for at least 10 years now.

Mark

Re: 8-byte register values on a 32-bit machine

[Mark Kettenis]

   Date: Sat, 1 Mar 2003 11:09:29 -0800
   From: Joel Brobecker <brobecker@gnat.com>

   > Yup, that's defenitely what it does for stabs, and from looking at the
   > code, it does it for other debug formats as well (including dwarf-2).
   > Right now, GDB interprets this as that the variable is stored in
   > consecutive registers starting at the register number indicated by the
   > debug info.  I have a strong suspicion that there are several GDB
   > targets that rely on this behaviour.  However, it isn't working for
   > the i386 since GCC allocates the registers in an order that's
   > different from the order that GDB uses.

   What I have seen as well is GCC an 8 bytes structure over 2 registers
   (2 fields of 4 bytes, one field on each register). The first register
   used (and specified in the stabs info) was %ebx, and the next one was
   sort of consecutive. It was %esi. The only thing is that there are two
   special registers in the middle (%esp, and %ebp) :-).

Yup, GCC allocates %esi after %ebx.  By the way, the fact that GDB
"thinks" that %esp follows %ebx makes things very interesting if you
happen to modify the last 4 bytes of said structure.  This will make
GDB modify the stack pointer, which most likely makes your program
blow up.

   Because of this, even if we modified GCC to allocate the registers in
   the same order as the GDB order (or modify the GDB order, if that's
   possible), we'll still have situations where this is not going to work.

Modifying GCC probably wouldn't be a good idea.  The order on which
GCC allocates the registers seems to be chosen such that it generates
optimized code.  Modifying the GDB order isn't possible (yet) because
of the remote protocol.

   I think we've lost the stabs battle.

Actually, the order in which GCC allocates its registers has been the
same for many years (at least since GCC 2.6.3 which was released in
1994).  We only need to teach GDB this order in order to make GCC do
the right thing for code generated by any version of GCC that's still
in wide use.  I posted a preliminary patch that does this early
februari.  If we're concerned about aother compilers than GCC, we can
probably tweak things that we only use the heuristics in my patch when
the code was compiled by GCC.

   So I started to look into the DWARF2 format, but could not find
   anything that helps. Does anybody know if this format supports this
   sort of situation?

The idea was that DWARF2 location expressions could help.  I believe
GCC should emit location descriptors that are concatenation of
locations, just like it already does for complex variables.

Mark

Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

For concreteness, suppose that the user has a structure with
two integers in it, and sizeof(int) is the natural register size
(which of course has been the design principle for C for decades).

  struct point
  {
    int x;
    int y;
  };

  struct point p1 = { 1234, 5678 };

Everybody's favorite output is:

  (gdb) print p1
  $1 = {1234, 5678}

Right now gdb can print lies:

  (gdb) print p1
  $1 = {1234, -8675309}

Incorrect data is much worse than no data at all.  Instead of iterating
over registers, I would like gdb to print:

  (gdb) print p1
  $1 = {1234, <unknown>}

I'm not stuck on "<unknown>".  It can be any string which indicates the
debugger can't tell the user what's in p1.y.

The heinous part is that gdb *knows* it is pulling some register value out of
its ass for p1.y.  I understand that on some targets, gcc and gdb might agree
on register number allocation (ignore for the moment that there are other
compilers besides gcc).  Okay, for targets where we have a guarantee about
that, then enable sequential register access.  But i686-pc-linux-gnu is
definitely not such a target.

Somewhat worse is:

  (gdb) print p1
  $1 = <unknown>

If the compiler tells us that an 8-byte variable is in a 4-byte register,
I feel comfortable printing the first 4 bytes.  But I would actually
printing no values to printing incorrect values.

If a debug format has enough information to print {1234, 5678},
that's great.  And we should ask gcc to give us that much information
in all the formats we can get to.  If we're lucky, then stabs+ will
become obsolete faster than people start seeing more multi-register
variables.  :)

Michael C

Re: 8-byte register values on a 32-bit machine

[Joel Brobecker]

> Yup, that's defenitely what it does for stabs, and from looking at the
> code, it does it for other debug formats as well (including dwarf-2).
> Right now, GDB interprets this as that the variable is stored in
> consecutive registers starting at the register number indicated by the
> debug info.  I have a strong suspicion that there are several GDB
> targets that rely on this behaviour.  However, it isn't working for
> the i386 since GCC allocates the registers in an order that's
> different from the order that GDB uses.

What I have seen as well is GCC an 8 bytes structure over 2 registers
(2 fields of 4 bytes, one field on each register). The first register
used (and specified in the stabs info) was %ebx, and the next one was
sort of consecutive. It was %esi. The only thing is that there are two
special registers in the middle (%esp, and %ebp) :-).

Because of this, even if we modified GCC to allocate the registers in
the same order as the GDB order (or modify the GDB order, if that's
possible), we'll still have situations where this is not going to work.

I think we've lost the stabs battle. So I started to look into the
DWARF2 format, but could not find anything that helps. Does anybody know
if this format supports this sort of situation?

-- 
Joel

Re: 8-byte register values on a 32-bit machine

[Mark Kettenis]

Michael Elizabeth Chastain <mec@shout.net> writes:

> I saw a regression in gdb.base/store.exp this week:
> 
>   gdb.base/store.exp: new check struct 4
>     PASS -> FAIL
> 
> This happens with gcc 2.95.3 -gdwarf-2.
> 
> This happens because gcc 2.95.3 puts an 8-byte variable into a pair of
> 4-byte registers.  (gcc 3.2.2 puts the variable into memory so the
> problem never arises -- but I bet it will come back for things like
> FORTRAN complex numbers, which are very natural for register pairs).

Please see the thread starting with:

   http://sources.redhat.com/ml/gdb/2003-02/msg00007.html

for a related discussion.

> But I suspect that gcc 2.95.3 tells us about just one register and that
> we can't win.  But gdb can at least say "hmmm, you are trying to print 8
> bytes from reg0, I can't do that", rather than print 4 bytes of correct
> information and 4 bytes of rat poison.  I think that would be acceptable
> support for 2.95.3.

Yup, that's defenitely what it does for stabs, and from looking at the
code, it does it for other debug formats as well (including dwarf-2).
Right now, GDB interprets this as that the variable is stored in
consecutive registers starting at the register number indicated by the
debug info.  I have a strong suspicion that there are several GDB
targets that rely on this behaviour.  However, it isn't working for
the i386 since GCC allocates the registers in an order that's
different from the order that GDB uses.

8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain]

I saw a regression in gdb.base/store.exp this week:

  gdb.base/store.exp: new check struct 4
    PASS -> FAIL

This happens with gcc 2.95.3 -gdwarf-2.

This happens because gcc 2.95.3 puts an 8-byte variable into a pair of
4-byte registers.  (gcc 3.2.2 puts the variable into memory so the
problem never arises -- but I bet it will come back for things like
FORTRAN complex numbers, which are very natural for register pairs).

It happened this particular week because the old dwarf-2 code had some
code to handle multi-register variables, although the code doesn't
appear to work for me.  The new dwarf-2 code just completely spaces
in the case of multi-register variables.

We need to figure out what the right symbol table information is for
multi-register variables.  If gcc is emitting good symbol table
information, gdb can do its job, and I can write a test case for it.

But I suspect that gcc 2.95.3 tells us about just one register and that
we can't win.  But gdb can at least say "hmmm, you are trying to print 8
bytes from reg0, I can't do that", rather than print 4 bytes of correct
information and 4 bytes of rat poison.  I think that would be acceptable
support for 2.95.3.

I filed a PR and I'll attach some executables to it.

Michael C