Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>,
	Stan Shebs <stanshebs@earthlink.net>,
	 GDB Patches <gdb-patches@sourceware.org>,
	Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: [PATCH, testsuite] Don't run SREC, IHEX and TEKHEX tests for MIPS N64.
Date: Wed, 03 Jul 2013 19:23:00 -0000	[thread overview]
Message-ID: <51D47A05.9020404@codesourcery.com> (raw)
In-Reply-To: <51D43DBB.5090803@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

On 07/03/2013 12:05 PM, Pedro Alves wrote:
> On 07/02/2013 07:50 PM, Luis Machado wrote:
>> -
>> -if {[istarget "spu*-*-*"]} then {
>> -    # The internal address format used for the combined Cell/B.E.
>> -    # debugger requires 64-bit.
>> -    set is64bitonly "yes"
>> -}
>> -
>
> I'm not sure this equates to sizeof pointer == 64-bit.
> This bit may need to be retained.  [Adding Ulrich].

Fair enough. Ulrich, let me know if the pointer check in the attached 
patch doesn't make sense for Cell BE.

>
>> +
>> +    set sizeof_function_ptr [get_sizeof "void (*)(void)" 8]
>> +    set sizeof_data_ptr [get_sizeof "void *" 8]
>> +    if {${sizeof_function_ptr} != 4 && ${sizeof_data_ptr} != 4} then {
>> +	set is64bitonly "yes"
>> +    }
>> +}
>> +
>
> srec (etc.) is most used in small embedded targets (e.g., those
> that include dsrec.o in the configure.tgt), consequently
> that's where the test is most useful.  Such targets
> are the most likely to have 16-bit pointers (< 4 bytes).
> E.g., h8300, etc.  Looks like this ends up causing the tests to
> be skipped there too.  IOW, a better check would be:
>
>     if {${sizeof_function_ptr} > 4 || ${sizeof_data_ptr} > 4} then {
>

Ah, yes. This check is indeed better. Follows an updated patch that does 
this.

> But, this change also means we have reduced routine-checking,
> as most people test on x86_64.  I think we can do better.  The test
> works fine on e.g., x86_64, because programs get linked to low (< 32-bit)
> addresses by default.  That's the point of:
>
> if [istarget "alpha*-*-*"] then {
>      # SREC etc cannot handle 64-bit addresses.  Force the test
>      # program into the low 31 bits of the address space.
>      lappend options "additional_flags=-Wl,-taso"
> }
>
> (For MIPS N64, if you wanted, I guess you could do similarly
>   to Alpha, and rebuild with:
>
>    lappend options "ldflags=-Wl,-Tdata=0x600000"
>
>   to force use of low addresses.)
>
> IOW, instead of checking for ABI pointer sizes, I think it'd
> be better to test for the actual address size of one the
> variables dumped.  That is, check that &intarray is < 32-bit.
>

If lack of coverage for x86_64 running things on low addresses is a 
problem, we can add an exception for x86_64, what do you think? Adding 
these exceptions usually polute the testcases though.

As for MIPS, attempting to force the use of low addresses, just like 
alpha, seems to do more than what the tools expect at the moment, and i 
get a SIGSEGV in the dynamic loader.

Luis

[-- Attachment #2: dump.diff --]
[-- Type: text/x-patch, Size: 1978 bytes --]

2013-07-03  Luis Machado  <lgustavo@codesourcery.com>

	* gdb.base/dump.exp: Update copyright line.
	Remove arch-specific tests and do a generic pointer size
	check to set is64bitonly correctly.

Index: gdb/testsuite/gdb.base/dump.exp
===================================================================
--- gdb/testsuite/gdb.base/dump.exp	(revision 415997)
+++ gdb/testsuite/gdb.base/dump.exp	(working copy)
@@ -32,16 +32,6 @@
     lappend options "additional_flags=-Wl,-taso"
 }
 
-if {[istarget "ia64*-*-*"] || [istarget "hppa64-*-*"]} then {
-    set is64bitonly "yes"
-}
-
-if {[istarget "spu*-*-*"]} then {
-    # The internal address format used for the combined Cell/B.E.
-    # debugger requires 64-bit.
-    set is64bitonly "yes"
-}
-
 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable ${options}] != "" } {
      untested dump.exp
      return -1
@@ -58,6 +48,23 @@
 
 gdb_load ${binfile}
 
+# Decide if we should test SREC, IHEX and TEKHEX formats.
+if {![istarget "alpha*-*-*"]} then {
+    # Check the size of a function pointer and of a data pointer.  If
+    # either of them is bigger than 4-bytes, assume our target has 64-bit
+    # addresses that are not supported by SREC, IHEX and TEKHEX.  We
+    # skip those tests then.
+    # If we error out below, we use the defaults (8 bytes) and skip
+    # the SREC, IHEX and TEKHEX tests just to be safe.
+    
+    set sizeof_function_ptr [get_sizeof "&main" 8]
+    set sizeof_data_ptr [get_sizeof "&intarray" 8]
+
+    if {${sizeof_function_ptr} > 4 || ${sizeof_data_ptr} > 4} then {
+	set is64bitonly "yes"
+    }
+}
+
 # Clean up any stale output files from previous test runs
 
 remote_exec build "rm -f intarr1.bin intarr1b.bin intarr1.ihex intarr1.srec intarr1.tekhex intarr2.bin intarr2b.bin intarr2.ihex intarr2.srec intarr2.tekhex intstr1.bin intstr1b.bin intstr1.ihex intstr1.srec intstr1.tekhex intstr2.bin intstr2b.bin intstr2.ihex intstr2.srec intstr2.tekhex intarr3.srec"

  reply	other threads:[~2013-07-03 19:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01 16:24 Luis Machado
2013-07-02 14:37 ` Yao Qi
2013-07-02 14:45   ` Luis Machado
2013-07-03  0:03     ` Yao Qi
2013-07-02 16:47 ` Tom Tromey
2013-07-02 16:51   ` Luis Machado
2013-07-02 17:19     ` Stan Shebs
2013-07-02 18:10       ` Tom Tromey
2013-07-02 18:50         ` Luis Machado
2013-07-02 20:55           ` Tom Tromey
2013-07-03 15:05           ` Pedro Alves
2013-07-03 19:23             ` Luis Machado [this message]
2013-07-03 19:26               ` Pedro Alves
2013-07-03 20:19                 ` Luis Machado
2013-07-04  8:11                   ` Pedro Alves
2013-07-06  2:41                     ` Luis Machado
2013-07-03 20:35               ` Maciej W. Rozycki
2013-07-03 20:54                 ` Luis Machado
2013-07-03 21:08                   ` Maciej W. Rozycki
2013-07-04 11:48                     ` Luis Machado
2013-07-04 12:13                       ` Maciej W. Rozycki
2013-07-04 12:21                         ` Luis Machado
2013-07-04 13:22               ` Ulrich Weigand
2013-07-04 13:24                 ` Luis Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D47A05.9020404@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=stanshebs@earthlink.net \
    --cc=tromey@redhat.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox