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)
{
next prev parent 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).