public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Pedro Alves <alves.ped@gmail.com>
Cc: Pedro Alves <palves@redhat.com>,
	       Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>,
	       Jan Kratochvil <jan.kratochvil@redhat.com>,
	gdb-patches@sourceware.org,
	       Ulrich Weigand <uweigand@de.ibm.com>,
	       Andreas Krebbel <krebbel@linux.vnet.ibm.com>,
	       Omair Javaid <omair.javaid@linaro.org>
Subject: Re: [PATCH] Fix possible alignment issue with dw2-dir-file-name test case
Date: Mon, 20 Jan 2014 19:47:00 -0000	[thread overview]
Message-ID: <87zjmq1lmv.fsf@br87z6lw.de.ibm.com> (raw)
In-Reply-To: <52D97460.1040206@gmail.com> (Pedro Alves's message of "Fri, 17	Jan 2014 18:20:16 +0000")

On Fri, Jan 17 2014, Pedro Alves wrote:

> BTW,
>
> (adding Omair)
>
> On 01/17/2014 05:58 PM, Andreas Arnez wrote:
>> +/* Notes: (1) The '*_start' label below is needed because 'name' may
>> +   point to a function descriptor instead of to the actual code.  (2)
>> +   The '.balign' should specify the highest possible function
>> +   alignment across all supported architectures, such that the label
>> +   never points into the alignment gap.  */
>> +
>>  #define FUNC(name)					\
>> -  void							\
>> +  asm (".balign 8");					\
>> +  asm (#name "_start: .globl " #name "_start\n");	\
>> +  static void						\
>>    name (void)						\
>
> Not sure you were following the
>  "testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM"
> thread.  Seems to me this exact same thing should be done to
> dw2-ifort-parameter.c.  I assume that test is currently failing
> on ppc64 for the exact same reason, and that if it's not failing
> on S390 with current gcc, it'll be by lucky alignment.  I believe
> this approach should fix Thumb there as well.  Can you guys
> coordinate on handling that test?  Thanks.

I haven't been following this thread, but the test case indeed fails on
s390x (64 bit) -- not just with a new GCC.

* On s390x, the test case fails like this:

        Breakpoint 1, 0x00000000800005d2 in func (param=<error reading
        variable: Cannot access memory at address 0x0>)
        (gdb) p/x param
        Cannot access memory at address 0x0

  Note that the debug info looks correct, and all addresses fit into
  four bytes.  Still, the failure disappears when changing the DWARF
  pointer size to 8.  Thus it seems that the address size mismatch
  causes confusion somewhere in GDB on big-endian systems.

* On PPC64, 'func' and 'main' are function descriptors and don't point
  to the actual code.  Thus the usage of these symbols in
  dw2-ifort-parameter-debug.S is broken (similar to what has been
  discussed in the thread, I think).  But once this is fixed, the issue
  above is surfaced.

For illustration, the patch below "fixes" both issues on PPC64.
However, for a real fix I think we should find the root cause for the
first issue (which I haven't dug much into yet).

-----
	Modified   gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
index c7dd9be..7e65c70 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
@@ -22,21 +22,21 @@
 .Lcu1_start:
 	.2byte	2				/* DWARF Version */
 	.4byte	.Labbrev1_begin			/* Offset into abbrev section */
-	.byte	4				/* Pointer size */
+	.byte	8				/* Pointer size */
 
 	/* CU die */
 	.uleb128 1				/* Abbrev: DW_TAG_compile_unit */
 	.ascii	"file1.txt\0"			/* DW_AT_name */
 	.ascii	"GNU C 3.3.3\0"			/* DW_AT_producer */
 	.byte	1				/* DW_AT_language (C) */
-	.4byte	func				/* DW_AT_low_pc */
-	.4byte	main				/* DW_AT_high_pc */
+	.8byte	func_start			/* DW_AT_low_pc */
+	.8byte	func_end			/* DW_AT_high_pc */
 
 	.uleb128	2			/* Abbrev: DW_TAG_subprogram */
 	.byte		1			/* DW_AT_external */
 	.ascii		"func\0"		/* DW_AT_name */
-	.4byte		func			/* DW_AT_low_pc */
-	.4byte		main			/* DW_AT_high_pc */
+	.8byte		func_start		/* DW_AT_low_pc */
+	.8byte		func_end		/* DW_AT_high_pc */
 
 	.uleb128	3			/* Abbrev: DW_TAG_formal_parameter */
 	.ascii		"param\0"		/* DW_AT_name */
@@ -44,7 +44,7 @@
 	.4byte		.Ltype_int - .Lcu1_begin	/* DW_AT_type */
 	.byte		2f - 1f			/* DW_AT_location */
 1:	.byte		3			/*   DW_OP_addr */
-	.4byte		ptr			/*   <addr> */
+	.8byte		ptr			/*   <addr> */
 	.byte		0x6			/*   DW_OP_deref */
 2:
 
	Modified   gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
index 361c44d..4474814 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
@@ -18,11 +18,17 @@
 int value = 0xdeadf00d;
 int *ptr = &value;
 
-void
+asm (".section	\".text\"");
+asm (".balign 8");
+asm ("func_start: .globl func_start");
+
+static void
 func (void)
 {
 }
 
+asm ("func_end: .globl func_end");
+
 int
 main (void)
 {

  reply	other threads:[~2014-01-20 19:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 18:00 Andreas Arnez
2014-01-10 11:29 ` Pedro Alves
2014-01-10 14:30   ` Andreas Arnez
2014-01-10 14:53     ` Jan Kratochvil
2014-01-10 16:39       ` Pedro Alves
2014-01-15 21:33         ` Edjunior Barbosa Machado
2014-01-16 14:37           ` Pedro Alves
2014-01-17 17:58             ` Andreas Arnez
2014-01-17 18:09               ` Pedro Alves
2014-01-17 18:20                 ` Pedro Alves
2014-01-20 19:47                   ` Andreas Arnez [this message]
2014-01-22 13:15                     ` Pedro Alves
2014-01-17 18:21               ` Edjunior Barbosa Machado
2014-01-22 16:13               ` Andreas Krebbel
2014-01-10 15:32     ` Pedro Alves

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=87zjmq1lmv.fsf@br87z6lw.de.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=alves.ped@gmail.com \
    --cc=emachado@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=omair.javaid@linaro.org \
    --cc=palves@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).