headers
David Carlton | 1 Oct 2003 01:14

Re: [patch/rfc] Deprecate REGISTER_VIRTUAL_SIZE

On Tue, 30 Sep 2003 16:28:26 -0400, Andrew Cagney <ac131313 <at> redhat.com> said:

> I've checked this in.

>> 2003-09-27  Andrew Cagney  <cagney <at> redhat.com>
>> * gdbarch.sh (DEPRECATED_REGISTER_VIRTUAL_SIZE): Rename
>> REGISTER_VIRTUAL_SIZE.
>> * gdbarch.h, gdbarch.c: Regenerate.
>> * vax-tdep.h, sparc-tdep.c, regcache.h: Update.
>> * regcache.c, mn10300-tdep.c, mips-tdep.c: Update.
>> * infcmd.c, frame.c, findvar.c, cris-tdep.c: Update.
>> Index: doc/ChangeLog
>> 2003-09-22  Andrew Cagney  <cagney <at> redhat.com>
>> * gdbint.texinfo (Target Architecture Definition): Rename
>> REGISTER_VIRTUAL_SIZE to DEPRECATED_REGISTER_VIRTUAL_SIZE.
>> (Target Architecture Definition): Index: mi/ChangeLog
>> 2003-09-22  Andrew Cagney  <cagney <at> redhat.com>
>> * mi-main.c: Rename REGISTER_VIRTUAL_SIZE to
>> DEPRECATED_REGISTER_VIRTUAL_SIZE.

Missed one in insight; I've committed the patch below as obvious.

I saw somebody using insight today; it looked really cool.  If my
hands didn't hate pointing devices, I'd be sorely tempted to
switch...

David Carlton
carlton <at> kealia.com

2003-09-30  David Carlton  <carlton <at> kealia.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Elizabeth Chastain | 1 Oct 2003 06:12

Re: RFA: Don't include value of expression in pc-fp.exp test name

mec> Proofread.  Tested on my test bed with 10 configurations.
mec> All the gdb.sum's come out identical now.

jimb> Fantastic.  I think this deserves mention in NEWS.

Jim's being facetious, I think, but it makes me realize that
I should say: all the gdb.sum's for pc-fp.exp come out identical.
There are still about 6 other files to hit.

Michael C
Nitpicky Bandwidth Waster

===

  2003-09-30  Jim Blandy  <jimb <at> redhat.com>

	  * gdb.base/pc-fp.exp (get_valueofx): Don't include the value of
	  the expression in the pass message.  This just creates spurious
	  differences in summary files.
Permalink | Reply | 0 comments |
headers
Andrew Cagney | 1 Oct 2003 16:32
Picon
Favicon

Re: [v2] Re: RFA/RFC: vCont for the remote protocol [doco]

Looks good.  Can you send it as a formal proposal (as a protocol change) 
to gdb <at> , then give it a week?

Andrew

> - <at> item  <at> code{v} --- reserved
> + <at> item  <at> code{v} --- verbose packet prefix
>  
> -Reserved for future use.
> +Packets starting with  <at> code{v} are identified by a multi-letter name,
> +up to the first  <at> code{;} or  <at> code{?} (or the end of the packet).

> + <at> item  <at> code{vCont}[; <at> var{action}[ <at> code{:} <at> var{tid}]]... --- extended resume
> + <at> cindex  <at> code{vCont} packet
> +
> +Resume the inferior.  Different actions may be specified for each thread.
> +If an action is specified with no  <at> var{tid}, then it is applied to any
> +threads that don't have a specific action specified; if no default action is
> +specified than other threads should remain stopped.  Multiple default
> +actions are an error.  Thread IDs are specified in hexadecimal.
> +Currently supported actions are:

Should it specify that no action is also an error?

> + <at> table  <at> code
> + <at> item c
> +Continue
> + <at> item C <at> var{sig}
> +Continue with signal  <at> var{sig}
> + <at> item s
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Cagney | 1 Oct 2003 17:31
Picon
Favicon

Re: RFA: Don't include value of expression in pc-fp.exp test name

> Michael Elizabeth Chastain <mec <at> shout.net> writes:
> 
> 
>> Yeah!  It makes my life easier!
>> 
>> You need to add '2003' to the copyright year to the top of pc-fp.exp.
>> 
>> Proofread.  Tested on my test bed with 10 configurations.
>> All the gdb.sum's come out identical now.
> 
> 
> Fantastic.  I think this deserves mention in NEWS.

As Michael well knows, supplemental information, such as which specific 
branch of a test passed or failed can be included in paren in the test 
message.  Any analysis tools comparing test results needs to accomodate 
this convention.

If you really want to remove this specific output, then what ever. 
However, please don't start removing the supplemental information willy 
nilly.  Instead, fix your script.

Andrew
Permalink | Reply | 1 comment |
headers
David Carlton | 1 Oct 2003 17:49

Re: RFA: Don't include value of expression in pc-fp.exp test name

On Wed, 01 Oct 2003 11:31:22 -0400, Andrew Cagney <ac131313 <at> redhat.com> said:

> As Michael well knows, supplemental information, such as which
> specific branch of a test passed or failed can be included in paren
> in the test message.  Any analysis tools comparing test results
> needs to accomodate this convention.

Then check in some analysis tools that do this.  Until you do that,
I'm going to stick with 'diff -u': it works fine for everything but
the threads test (where reordering is harder to get away with) and
pc-fp.exp.  From my point of view, all that you've accomplished by
putting that hex string in pc-fp.exp is made it more likely that I'll
ignore the test, just like I do with print-threads.exp and
schedlock.exp.

I really don't understand the motivation behind putting random stuff
in parentheses and then complaining that people aren't ignoring it.
If you want people to ignore it, and even encourage people to use
tools which shield them from it, then why have it there in the first
place?  I can see that making FAIL messages more verbose, especially
if the verbosity is in human-readable form.  But PASS messages, with
hex strings?  What am I supposed to do with that hex string?
Especially since I can get that data out of gdb.log if I really need
it.

David Carlton
carlton <at> kealia.com
Permalink | Reply | 0 comments |
headers
Michael Elizabeth Chastain | 1 Oct 2003 18:44

Re: RFA: Don't include value of expression in pc-fp.exp test name

ac> As Michael well knows, supplemental information, such as which specific 
ac> branch of a test passed or failed can be included in paren in the test 
ac> message.  Any analysis tools comparing test results needs to accomodate 
ac> this convention.

I don't know any such convention.  I'm looking at a typical gdb.sum.
There are 1523 instances of '(...)' in 112 different test scripts.
Most of these are part of the test name.

If you want to promulgate such a convention, put it in the docs,
and I'll start submitting patches to change all these test scripts,
or committing them as obvious fixes.

A better path would be to pick a character sequence which is unused,
such as '// ...'.

Michael C

===

gdb.base/all-bin.exp: continuing after dummy()
gdb.base/arithmet.exp: print x-(y+w)
gdb.base/arithmet.exp: print x/(y*w)
gdb.base/arithmet.exp: print x-(y/w)
gdb.base/arithmet.exp: print (x+y)*w
gdb.base/assign.exp: continuing after dummy()
gdb.base/attach.exp: (re)set file, before attach1
gdb.base/bitfields.exp: bitfield uniqueness (s1)
gdb.base/bitfields.exp: bitfield uniqueness (u1)
gdb.base/bitfields.exp: bitfield uniqueness (s2)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Elena Zannoni | 1 Oct 2003 19:34
Picon
Favicon

Re: [rfa] add 'parent' field to struct die_info

David Carlton writes:
 > On 30 Sep 2003 17:09:38 -0500, Jim Blandy <jimb <at> redhat.com> said:
 > 
 > > Looks great --- please commit.
 > 
 > Thanks, done.
 > 
 > > Adding the parent pointer is great.  But I also really appreciate the
 > > child/sibling rearrangement... the way it stands is really confusing,
 > > and I think this is much more intuitive.
 > 
 > That was my attitude, too: before, we were too closely tied to the
 > data structure that the debug info was originally stored in, for no
 > good reason.

May I suggest to add a comment where the structure is defined that explains
in plain English the structure/relations of the dies?
From the Dwarf manual:

"The ownership relation of debugging information entries is achieved
naturally because the debugging information is represented as a
tree. The nodes of the tree are the debugging information entries
themselves. The child entries of any node are exactly those debugging
information entries owned by that node. While the ownership relation
of the debugging information entries is represented as a tree, other
relations among the entries exist, for example, a pointer from an
entry representing a variable to another entry representing the type
of that variable. If all such relations are taken into account, the
debugging entries form a graph, not a tree. The tree itself is
represented by flattening it in prefix order. Each debugging
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Cagney | 1 Oct 2003 20:29
Picon
Favicon

Re: RFA: Don't include value of expression in pc-fp.exp test name

> ac> As Michael well knows, supplemental information, such as which specific 
> ac> branch of a test passed or failed can be included in paren in the test 
> ac> message.  Any analysis tools comparing test results needs to accomodate 
> ac> this convention.
> 
> I don't know any such convention.

Michael, you and I had an e-mail exchange about this very issue.  The 
end result, last time, was no change.

> I'm looking at a typical gdb.sum.
> There are 1523 instances of '(...)' in 112 different test scripts.
> Most of these are part of the test name.

To split hairs, I can see two cases:

- two runs within identical environments
I can see 'diff -u' reasonably working here.

- two runs within different environments
After paren stripping the results should be identical (or close two it).

For instance sizeof.exp contains various tests to check that sizes are 
sane.  The actual sizes found are included in the output.  That's fine 
since if the numbers were to change between runs the test results are 
pretty sunk.

Thanks to the advent of PIE (position independant code) it's now 
possible for the PC/FP to change between "100% identical" runs.  So for 
this specific case, what ever.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Snyder | 1 Oct 2003 20:37
Picon
Favicon

Re: [RFA] New threads test

Daniel Jacobowitz wrote:
> This is a test for the remote protocol issue I'm solving with vCont.  It
> also shows up in schedlock, but the simpler test makes it much clearer
> what's going wrong.  OK?
> 

Umm... what is going wrong?  What are you testing for here?
Permalink | Reply | 7 comments |
headers
Andrew Cagney | 1 Oct 2003 20:49
Picon
Favicon

Re: [patch/rfc] Simplify by assuming that the inferior frame was aligned

> Hello,
> 
> This simplifies inferior function call code by assuming that "struct_return" is always correct and
always using it to extract the "struct return value".
> 
> The MIPS inferior function call code was invalidating "struct_addr" by doing some local alignment.  Now
that the MIPS has a frame_align method that problem no longer occures (I've found no other code pulling
similar tricks).  Consequently, I believe that the attached simplification is now safe.
> 
> It's got lots of follow through.  In particular it allows the restructuring of value_being_returned and
print_return_value, and the elimination of VALUE_RETURNED_FROM_STACK.
> 
> Note that the change is only one line!  The rest is to alert the coder as to the status of various parts of GDB.
> 
> Baring comment, I'll look to commit this in 3-4 days,

I've checked this in.  Now to shuffle value_being_returned and 
print_return_value.

Andrew

2003-09-27  Andrew Cagney  <cagney <at> redhat.com>

	* infcall.c (call_function_by_hand): When STRUCT_RETURN, always
	use STRUCT_ADDR.  When not using "struct return convention", pass
	"0" to "value_being_returned".  Add FIXMEs.
	* infcmd.c (print_return_value): Pass an explicit 0/1 to
	value_being_returned.  Add comments.
	* values.c (value_being_returned): Add FIXME.
	* hppa-tdep.c (hppa_extract_struct_value_address): Add FIXME.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane