gdb.arch vs. gdb.base gcore test cases

gdb.arch vs. gdb.base gcore test cases

[Andreas Arnez]

The following two test cases are mostly identical, and their associated
C source files are exactly identical:

    gdb.arch/system-gcore.exp
    gdb.base/gcore.exp

Is there any specific reason for the two copies?  Just curious...

Re: gdb.arch vs. gdb.base gcore test cases

[Pedro Alves]

On 05/03/2013 12:15 PM, Andreas Arnez wrote:
> The following two test cases are mostly identical, and their associated
> C source files are exactly identical:
> 
>     gdb.arch/system-gcore.exp
>     gdb.base/gcore.exp
> 
> Is there any specific reason for the two copies?  Just curious...

Well, what does git blame, and the initial submission of the
corresponding patches say?  The answer probably lies in what makes them
"mostly identical" rather than "exactly identical" being arch
specific.  If the differences are really small, then we could merge
them into gcore.exp, using istarget to guard the arch specific bits.

-- 
Pedro Alves

Re: gdb.arch vs. gdb.base gcore test cases

[Andreas Arnez]

Pedro Alves <palves@redhat.com> writes:

> On 05/03/2013 12:15 PM, Andreas Arnez wrote:
>> The following two test cases are mostly identical, and their associated
>> C source files are exactly identical:
>> 
>>     gdb.arch/system-gcore.exp
>>     gdb.base/gcore.exp
>> 
>> Is there any specific reason for the two copies?  Just curious...
>
> Well, what does git blame, and the initial submission of the
> corresponding patches say?  The answer probably lies in what makes them
> "mostly identical" rather than "exactly identical" being arch
> specific.  If the differences are really small, then we could merge
> them into gcore.exp, using istarget to guard the arch specific bits.

The common test case was introduced some time ago:

    2002-01-08  Michael Snyder  <msnyder@redhat.com>
    
    	* gdb.base/gcore.exp: New test for generate-core-file command.
    	* gdb.base/gcore.c: Testcase for above.
    	* gdb.threads/gcore-thread.exp: New test for gcore (threaded).

The x86-specific one is newer; it was introduced with this change:

    2010-04-17  H.J. Lu  <hongjiu.lu@intel.com>
    
    	PR corefiles/11511
    	* gdb.arch/system-gcore.exp: New.
    	* gdb.arch/gcore.c: Likewise.

The only functional difference seems to be that system-gcore.exp adds a
new comparison (before/after) for the output from "info reg system".

Re: gdb.arch vs. gdb.base gcore test cases

[Pedro Alves]

On 05/03/2013 02:15 PM, Andreas Arnez wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> On 05/03/2013 12:15 PM, Andreas Arnez wrote:
>>> The following two test cases are mostly identical, and their associated
>>> C source files are exactly identical:
>>>
>>>     gdb.arch/system-gcore.exp
>>>     gdb.base/gcore.exp
>>>
>>> Is there any specific reason for the two copies?  Just curious...
>>
>> Well, what does git blame, and the initial submission of the
>> corresponding patches say?  The answer probably lies in what makes them
>> "mostly identical" rather than "exactly identical" being arch
>> specific.  If the differences are really small, then we could merge
>> them into gcore.exp, using istarget to guard the arch specific bits.

...

> The x86-specific one is newer; it was introduced with this change:
> 
>     2010-04-17  H.J. Lu  <hongjiu.lu@intel.com>
>     
>     	PR corefiles/11511
>     	* gdb.arch/system-gcore.exp: New.
>     	* gdb.arch/gcore.c: Likewise.
> 
> The only functional difference seems to be that system-gcore.exp adds a
> new comparison (before/after) for the output from "info reg system".

Did you check the original patch submission description in the
mailing list archives for a possible rationale?

Given that "system" is a predefined register group, I think
"info reg system" works on all targets, though it might come
out empty if no register is actually in that group on a given
target.  That seems fine for this test.

-- 
Pedro Alves

Re: gdb.arch vs. gdb.base gcore test cases

[Andreas Arnez]

Pedro Alves <palves@redhat.com> writes:

> Did you check the original patch submission description in the
> mailing list archives for a possible rationale?

Here's the associated patch submission:
  http://sourceware.org/ml/gdb-patches/2010-04/msg00534.html

It doesn't seem to contain a rationale for the system-gcore test case.

> Given that "system" is a predefined register group, I think
> "info reg system" works on all targets, though it might come
> out empty if no register is actually in that group on a given
> target.  That seems fine for this test.

Right, that's what I thought.  Thus a patch like this should make
gcore-system.exp obsolete (untested):

diff --git a/gdb/testsuite/gdb.base/gcore.exp b/gdb/testsuite/gdb.base/gcore.exp
index 33528fb..c9a202c 100644
--- a/gdb/testsuite/gdb.base/gcore.exp
+++ b/gdb/testsuite/gdb.base/gcore.exp
@@ -74,6 +74,7 @@ set print_prefix ".\[0123456789\]* = "
 set pre_corefile_backtrace [capture_command_output "backtrace" ""]
 set pre_corefile_regs [capture_command_output "info registers" ""]
 set pre_corefile_allregs [capture_command_output "info all-reg" ""]
+set pre_corefile_sysregs [capture_command_output "info reg system" ""]
 set pre_corefile_static_array \
 	[capture_command_output "print static_array" "$print_prefix"]
 set pre_corefile_uninit_array \
@@ -143,6 +144,13 @@ if ![string compare $pre_corefile_allregs $post_corefile_allregs] then {
     fail "corefile restored all registers"
 }
 
+set post_corefile_sysregs [capture_command_output "info reg system" ""]
+if ![string compare $pre_corefile_sysregs $post_corefile_sysregs] then {
+    pass "corefile restored system registers"
+} else {
+    fail "corefile restored system registers"
+}
+
 set post_corefile_extern_array \
 	[capture_command_output "print extern_array" "$print_prefix"]
 if ![string compare $pre_corefile_extern_array $post_corefile_extern_array]  {

Re: gdb.arch vs. gdb.base gcore test cases

[Pedro Alves]

On 05/03/2013 03:48 PM, Andreas Arnez wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Did you check the original patch submission description in the
>> mailing list archives for a possible rationale?
> 
> Here's the associated patch submission:
>   http://sourceware.org/ml/gdb-patches/2010-04/msg00534.html
> 
> It doesn't seem to contain a rationale for the system-gcore test case.
> 
>> Given that "system" is a predefined register group, I think
>> "info reg system" works on all targets, though it might come
>> out empty if no register is actually in that group on a given
>> target.  That seems fine for this test.
> 
> Right, that's what I thought.  

Then why didn't you say so from the get go? ;-)

Thus a patch like this should make
> gcore-system.exp obsolete (untested):

Okay with a ChangeLog entry, and if it passes testing.

Thanks,
-- 
Pedro Alves

Re: gdb.arch vs. gdb.base gcore test cases

[Pedro Alves]

On 05/03/2013 04:00 PM, Pedro Alves wrote:

>> > Right, that's what I thought.  
> Then why didn't you say so from the get go? ;-)

Apologies, reading back, this might not sound like what I wanted
to hint at.  All I meant was that including that info up thread
would have saved me some investigative work.

Thanks,
-- 
Pedro Alves

Re: gdb.arch vs. gdb.base gcore test cases

[Andreas Arnez]

Pedro Alves <palves@redhat.com> writes:

> Thus a patch like this should make
>> gcore-system.exp obsolete (untested):
>
> Okay with a ChangeLog entry, and if it passes testing.

OK, I'll send a patch to gdb-patches then.