[PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

gdb.dwarf2/dw2-ifort-parameter fails on ARM because the dwarf2 debug
information being created by gdb.dwarf2/dw2-ifort-parameter-debug.S
gets corrupted because LSB of function addresses is ON in Thumb mode.
ARM instructions are word aligned and LSB of instruction address is
used to determine whether code being branched to is Thumb or ARM code.
This patch solves the problem by decrementing function address by one
in thumb mode. This patch has been tested on x86_64 and arm7 machines.

gdb/testsuite/ChangeLog:

2013-07-15  Omair Javaid  <Omair.Javaid@linaro.org>

	* gdb.dwarf2/dw2-ifort-parameter-debug.S: Updated to use correct
	function addresses while creating debug info in ARM Thumb mode.

===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S,v
retrieving revision 1.4
diff -u -p -r1.4 dw2-ifort-parameter-debug.S
--- gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S        1 Jan 2013
06:33:28 -0000  1.4
+++ gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S        19 Jun 2013
18:34:44 -0000
@@ -29,15 +29,35 @@
        .ascii  "file1.txt\0"                   /* DW_AT_name */
        .ascii  "GNU C 3.3.3\0"                 /* DW_AT_producer */
        .byte   1                               /* DW_AT_language (C) */
+
+#ifndef __thumb__
+
        .4byte  func                            /* DW_AT_low_pc */
        .4byte  main                            /* DW_AT_high_pc */

+#else
+
+       .4byte          func-1                  /* DW_AT_low_pc */
+       .4byte          main-1                  /* DW_AT_high_pc */
+
+#endif
+
        .uleb128        2                       /* Abbrev: DW_TAG_subprogram */
        .byte           1                       /* DW_AT_external */
        .ascii          "func\0"                /* DW_AT_name */
+
+#ifndef __thumb__
+
        .4byte          func                    /* DW_AT_low_pc */
        .4byte          main                    /* DW_AT_high_pc */

+#else
+
+       .4byte          func-1                  /* DW_AT_low_pc */
+       .4byte          main-1                  /* DW_AT_high_pc */
+
+#endif
+
        .uleb128        3                       /* Abbrev:
DW_TAG_formal_parameter */
        .ascii          "param\0"               /* DW_AT_name */
        .byte           1                       /* DW_AT_variable_parameter */

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Yao Qi]

On 07/15/2013 06:25 PM, Omair Javaid wrote:
> gdb.dwarf2/dw2-ifort-parameter fails on ARM because the dwarf2 debug
> information being created by gdb.dwarf2/dw2-ifort-parameter-debug.S
> gets corrupted because LSB of function addresses is ON in Thumb mode.
> ARM instructions are word aligned and LSB of instruction address is
> used to determine whether code being branched to is Thumb or ARM code.
> This patch solves the problem by decrementing function address by one
> in thumb mode. This patch has been tested on x86_64 and arm7 machines.

Omair,
IMO, the last bit of "function pointer value" indicates whether the 
target function is an ARM or a thumb one.  The "address" should still 
refer to the actual address, as "DWARF should tell the truth".  What is 
wrong *without* your patch?

-- 
Yao (齐尧)

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

Yao,

Thanks for your feedback.

Here is the testcase without my patch and breakpoint address gets
adjusted because an odd address was being used:

(gdb) break func
warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
Breakpoint 1 at 0x83bc (2 locations)
(gdb) run
Starting program:
/home/linaro/omair/bug_triage/gdb-7.6/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter
warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
warning: Breakpoint 1 address previously adjusted from 0x000083bd to 0x000083bc.

Breakpoint 1, 0x000083bc in func ()
(gdb) p/x param
No symbol "param" in current context.
(gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param
testcase ./gdb.dwarf2/dw2-ifort-parameter.exp completed in 0 seconds

Can you suggest any other way to fix this issue.

Thanks you for you help.


--
Omair.

On 16 July 2013 03:52, Yao Qi <yao@codesourcery.com> wrote:
> On 07/15/2013 06:25 PM, Omair Javaid wrote:
>>
>> gdb.dwarf2/dw2-ifort-parameter fails on ARM because the dwarf2 debug
>> information being created by gdb.dwarf2/dw2-ifort-parameter-debug.S
>> gets corrupted because LSB of function addresses is ON in Thumb mode.
>> ARM instructions are word aligned and LSB of instruction address is
>> used to determine whether code being branched to is Thumb or ARM code.
>> This patch solves the problem by decrementing function address by one
>> in thumb mode. This patch has been tested on x86_64 and arm7 machines.
>
>
> Omair,
> IMO, the last bit of "function pointer value" indicates whether the target
> function is an ARM or a thumb one.  The "address" should still refer to the
> actual address, as "DWARF should tell the truth".  What is wrong *without*
> your patch?
>
> --
> Yao (齐尧)

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

On 19 September 2013 20:30, Omair Javaid <omair.javaid@linaro.org> wrote:
> Yao,
>
> Thanks for your feedback.
>
> Here is the testcase without my patch and breakpoint address gets
> adjusted because an odd address was being used:
>
> (gdb) break func
> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> Breakpoint 1 at 0x83bc (2 locations)
> (gdb) run
> Starting program:
> /home/linaro/omair/bug_triage/gdb-7.6/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter
> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> warning: Breakpoint 1 address previously adjusted from 0x000083bd to 0x000083bc.
>
> Breakpoint 1, 0x000083bc in func ()
> (gdb) p/x param
> No symbol "param" in current context.
> (gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param
> testcase ./gdb.dwarf2/dw2-ifort-parameter.exp completed in 0 seconds
>
> Can you suggest any other way to fix this issue.
>
> Thanks you for you help.
>
>
> --
> Omair.
>
> On 16 July 2013 03:52, Yao Qi <yao@codesourcery.com> wrote:
>> On 07/15/2013 06:25 PM, Omair Javaid wrote:
>>>
>>> gdb.dwarf2/dw2-ifort-parameter fails on ARM because the dwarf2 debug
>>> information being created by gdb.dwarf2/dw2-ifort-parameter-debug.S
>>> gets corrupted because LSB of function addresses is ON in Thumb mode.
>>> ARM instructions are word aligned and LSB of instruction address is
>>> used to determine whether code being branched to is Thumb or ARM code.
>>> This patch solves the problem by decrementing function address by one
>>> in thumb mode. This patch has been tested on x86_64 and arm7 machines.
>>
>>
>> Omair,
>> IMO, the last bit of "function pointer value" indicates whether the target
>> function is an ARM or a thumb one.  The "address" should still refer to the
>> actual address, as "DWARF should tell the truth".  What is wrong *without*
>> your patch?
>>
>> --
>> Yao (齐尧)

Ping? Any suggestions? I can actually add labels in c code of this
test case and use those labels instead of function pointer values.
Would that be fine?

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Yao Qi]

[Sorry for being late]

On 09/19/2013 11:30 PM, Omair Javaid wrote:
> (gdb) break func
> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> Breakpoint 1 at 0x83bc (2 locations)

'break func' should insert a breakpoint at an address A after the first
several instructions of function func, due to the effect of skip
prologue.  Address A should be an address of a thumb instruction, so it
should be 2-byte aligned.  In this case, the address should be
0x000083bc.  I'd like to check why 0x000083bd is generated, and
probably we should use gdbarch_addr_bits_remove somewhere.

-- 
Yao (齐尧)

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

On Mon 11 Nov 2013 02:36:40 PM PKT, Yao Qi wrote:
> [Sorry for being late]
>
> On 09/19/2013 11:30 PM, Omair Javaid wrote:
>> (gdb) break func
>> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
>> Breakpoint 1 at 0x83bc (2 locations)
>
> 'break func' should insert a breakpoint at an address A after the first
> several instructions of function func, due to the effect of skip
> prologue.  Address A should be an address of a thumb instruction, so it
> should be 2-byte aligned.  In this case, the address should be
> 0x000083bc.  I'd like to check why 0x000083bd is generated, and
> probably we should use gdbarch_addr_bits_remove somewhere.
>

There seemed no problem with how breakpoint addresses were being adjusted. 
This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
using compile time addresses so in case of arm (thumb mode) the least
significant bits of compile time address are set to 1. For that reason 
0x000083bd was being used as a breakpoint address func. This test was using
that compile time address to insert breakpoint and that breakpoint was being
adjusted to an instruction before the actual intended breakpoint instruction.
I have just added a simple stepi test to make sure that we are in correct
scope when we test for a fortran constant param. This works fine for both
arm and x86.

gdb/testsuite/ChangeLog:

2014-01-16  Omair Javaid  <Omair.Javaid@linaro.org>

	* gdb.dwarf2/dw2-ifort-parameter.exp: Adds a new stepi test.

---
 gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
index 35fb0fa..8f49eea 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
@@ -33,4 +33,6 @@ if ![runto func] {
     return -1
 }
 
+gdb_test "stepi" ".*"
+
 gdb_test "p/x param" " = 0xdeadf00d"
-- 
1.7.9.5

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Will Newton]

On 16 January 2014 09:03, Omair Javaid <omair.javaid@linaro.org> wrote:
> On Mon 11 Nov 2013 02:36:40 PM PKT, Yao Qi wrote:
>> [Sorry for being late]
>>
>> On 09/19/2013 11:30 PM, Omair Javaid wrote:
>>> (gdb) break func
>>> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
>>> Breakpoint 1 at 0x83bc (2 locations)
>>
>> 'break func' should insert a breakpoint at an address A after the first
>> several instructions of function func, due to the effect of skip
>> prologue.  Address A should be an address of a thumb instruction, so it
>> should be 2-byte aligned.  In this case, the address should be
>> 0x000083bc.  I'd like to check why 0x000083bd is generated, and
>> probably we should use gdbarch_addr_bits_remove somewhere.
>>
>
> There seemed no problem with how breakpoint addresses were being adjusted.
> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
> using compile time addresses so in case of arm (thumb mode) the least
> significant bits of compile time address are set to 1. For that reason
> 0x000083bd was being used as a breakpoint address func. This test was using
> that compile time address to insert breakpoint and that breakpoint was being
> adjusted to an instruction before the actual intended breakpoint instruction.
> I have just added a simple stepi test to make sure that we are in correct
> scope when we test for a fortran constant param. This works fine for both
> arm and x86.
>
> gdb/testsuite/ChangeLog:
>
> 2014-01-16  Omair Javaid  <Omair.Javaid@linaro.org>
>
>         * gdb.dwarf2/dw2-ifort-parameter.exp: Adds a new stepi test.
>
> ---
>  gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
> index 35fb0fa..8f49eea 100644
> --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
> +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.exp
> @@ -33,4 +33,6 @@ if ![runto func] {
>      return -1
>  }
>
> +gdb_test "stepi" ".*"
> +

I guess this could use a comment to explain why it is there.

-- 
Will Newton
Toolchain Working Group, Linaro

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Pedro Alves]

On 01/16/2014 09:03 AM, Omair Javaid wrote:

> There seemed no problem with how breakpoint addresses were being adjusted. 
> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
> using compile time addresses so in case of arm (thumb mode) the least
> significant bits of compile time address are set to 1. For that reason 
> 0x000083bd was being used as a breakpoint address func. 

OOC, what does the compiler debug info usually do instead to avoid this?

-- 
Pedro Alves

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Pedro Alves]

On 01/16/2014 09:48 AM, Pedro Alves wrote:
> On 01/16/2014 09:03 AM, Omair Javaid wrote:
> 
>> There seemed no problem with how breakpoint addresses were being adjusted. 
>> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
>> using compile time addresses so in case of arm (thumb mode) the least
>> significant bits of compile time address are set to 1. For that reason 
>> 0x000083bd was being used as a breakpoint address func. 
> 
> OOC, what does the compiler debug info usually do instead to avoid this?

Also:

> warning: Breakpoint address adjusted from 0x000083bd to 0x000083bc.
> Breakpoint 1 at 0x83bc (2 locations)

why 2 locations?

-- 
Pedro Alves

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

On 01/16/2014 02:48 PM, Pedro Alves wrote:
> On 01/16/2014 09:03 AM, Omair Javaid wrote:
> 
>> There seemed no problem with how breakpoint addresses were being adjusted. 
>> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
>> using compile time addresses so in case of arm (thumb mode) the least
>> significant bits of compile time address are set to 1. For that reason 
>> 0x000083bd was being used as a breakpoint address func. 
> 
> OOC, what does the compiler debug info usually do instead to avoid this?
> 

Here is what compiler generates when there are thumb functions to handle:
        .thumb_func
        .type func, %function
func:
.LFB0:

func is marked as thumb function and thus this func pointer will have the 
lower bit set. While .LFB0: non thumb label will be used to mark function
start address. Like this:         .4byte .LFB0 @ DW_AT_low_pc

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Pedro Alves]

On 01/16/2014 10:26 AM, Omair Javaid wrote:
> 
> 
> On 01/16/2014 02:48 PM, Pedro Alves wrote:
>> On 01/16/2014 09:03 AM, Omair Javaid wrote:
>>
>>> There seemed no problem with how breakpoint addresses were being adjusted. 
>>> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
>>> using compile time addresses so in case of arm (thumb mode) the least
>>> significant bits of compile time address are set to 1. For that reason 
>>> 0x000083bd was being used as a breakpoint address func. 
>>
>> OOC, what does the compiler debug info usually do instead to avoid this?
>>
> 
> Here is what compiler generates when there are thumb functions to handle:
>         .thumb_func
>         .type func, %function
> func:
> .LFB0:
> 
> func is marked as thumb function and thus this func pointer will have the 
> lower bit set. While .LFB0: non thumb label will be used to mark function
> start address. Like this:         .4byte .LFB0 @ DW_AT_low_pc

Ah.  I wonder if this works for you (and everyone).

---
 gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S | 4 ++--
 gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c       | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
index c7dd9be..6b08cb2 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
@@ -35,8 +35,8 @@
 	.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 */
+	.4byte		func_addr		/* DW_AT_low_pc */
+	.4byte		main_addr		/* DW_AT_high_pc */
 
 	.uleb128	3			/* Abbrev: DW_TAG_formal_parameter */
 	.ascii		"param\0"		/* DW_AT_name */
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
index 361c44d..c866b0f 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
@@ -29,3 +29,9 @@ main (void)
   func ();
   return 0;
 }
+
+/* Addresses represented as data symbols, thus without Thumb (etc.)
+   mode bits.  The dw2-ifort-parameter-debug.S file uses this as
+   func's low_pc/high_pc.  */
+extern void *func_addr __attribute__ ((alias ("func")));
+extern void *main_addr __attribute__ ((alias ("main")));
-- 
1.7.11.7

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

On Thu 16 Jan 2014 05:35:46 PM PKT, Pedro Alves wrote:
> On 01/16/2014 10:26 AM, Omair Javaid wrote:
>>
>>
>> On 01/16/2014 02:48 PM, Pedro Alves wrote:
>>> On 01/16/2014 09:03 AM, Omair Javaid wrote:
>>>
>>>> There seemed no problem with how breakpoint addresses were being adjusted. 
>>>> This test requires to build dwarf info by hand in dw2-ifort-parameter-debug.S
>>>> using compile time addresses so in case of arm (thumb mode) the least
>>>> significant bits of compile time address are set to 1. For that reason 
>>>> 0x000083bd was being used as a breakpoint address func. 
>>>
>>> OOC, what does the compiler debug info usually do instead to avoid this?
>>>
>>
>> Here is what compiler generates when there are thumb functions to handle:
>>         .thumb_func
>>         .type func, %function
>> func:
>> .LFB0:
>>
>> func is marked as thumb function and thus this func pointer will have the 
>> lower bit set. While .LFB0: non thumb label will be used to mark function
>> start address. Like this:         .4byte .LFB0 @ DW_AT_low_pc
>
> Ah.  I wonder if this works for you (and everyone).
>
> ---
>  gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S | 4 ++--
>  gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c       | 6 ++++++
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
> index c7dd9be..6b08cb2 100644
> --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
> +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter-debug.S
> @@ -35,8 +35,8 @@
>  	.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 */
> +	.4byte		func_addr		/* DW_AT_low_pc */
> +	.4byte		main_addr		/* DW_AT_high_pc */
>  
>  	.uleb128	3			/* Abbrev: DW_TAG_formal_parameter */
>  	.ascii		"param\0"		/* DW_AT_name */
> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
> index 361c44d..c866b0f 100644
> --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
> +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
> @@ -29,3 +29,9 @@ main (void)
>    func ();
>    return 0;
>  }
> +
> +/* Addresses represented as data symbols, thus without Thumb (etc.)
> +   mode bits.  The dw2-ifort-parameter-debug.S file uses this as
> +   func's low_pc/high_pc.  */
> +extern void *func_addr __attribute__ ((alias ("func")));
> +extern void *main_addr __attribute__ ((alias ("main")));

Patch doesnt fix the issue and builds after making changes to alias definition like:

extern void func_addr() __attribute__ ((alias ("func")));
extern void main_addr() __attribute__ ((alias ("main")));

I have actually tried similar stuff before by adding:

asm(".globl func_addr");
asm(".4byte func_addr");

but issues remains the same.

Heres the output with your patch:

warning: Breakpoint address adjusted from 0x000083c5 to 0x000083c4.
Breakpoint 1 at 0x83c4 (2 locations)
(gdb) run 
Starting program: /home/omair/gdb_dev/gdb/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter 
warning: Breakpoint address adjusted from 0x000083c5 to 0x000083c4.
warning: Breakpoint address adjusted from 0x000083c5 to 0x000083c4.
warning: Breakpoint address adjusted from 0x000083c5 to 0x000083c4.
warning: Breakpoint 1 address previously adjusted from 0x000083c5 to 0x000083c4.

Breakpoint 1, 0x000083c4 in func_addr ()
(gdb) p/x param
No symbol "param" in current context.
(gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param
testcase ./gdb.dwarf2/dw2-ifort-parameter.exp completed in 1 seconds

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Pedro Alves]

On 01/16/2014 01:55 PM, Omair Javaid wrote:
>> > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>> > index 361c44d..c866b0f 100644
>> > --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>> > +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>> > @@ -29,3 +29,9 @@ main (void)
>> >    func ();
>> >    return 0;
>> >  }
>> > +
>> > +/* Addresses represented as data symbols, thus without Thumb (etc.)
>> > +   mode bits.  The dw2-ifort-parameter-debug.S file uses this as
>> > +   func's low_pc/high_pc.  */
>> > +extern void *func_addr __attribute__ ((alias ("func")));
>> > +extern void *main_addr __attribute__ ((alias ("main")));
> Patch doesnt fix the issue and builds after making changes to alias definition like:

Odd.  Are you saying the patch didn't build for you?  It did for
me, in Thumb mode, and the debug info I saw looked right (no
thumb bit).

> extern void func_addr() __attribute__ ((alias ("func")));
> extern void main_addr() __attribute__ ((alias ("main")));

...
> but issues remains the same.

That's expected, as the whole point was making a data symbol
(void *), but that change makes it a function again (thus
ends up with the thumb bit set again).

-- 
Pedro Alves

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Omair Javaid]

On Thu 16 Jan 2014 07:00:37 PM PKT, Pedro Alves wrote:
> On 01/16/2014 01:55 PM, Omair Javaid wrote:
>>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>> index 361c44d..c866b0f 100644
>>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>> @@ -29,3 +29,9 @@ main (void)
>>>>    func ();
>>>>    return 0;
>>>>  }
>>>> +
>>>> +/* Addresses represented as data symbols, thus without Thumb (etc.)
>>>> +   mode bits.  The dw2-ifort-parameter-debug.S file uses this as
>>>> +   func's low_pc/high_pc.  */
>>>> +extern void *func_addr __attribute__ ((alias ("func")));
>>>> +extern void *main_addr __attribute__ ((alias ("main")));
>> Patch doesnt fix the issue and builds after making changes to alias definition like:
>
> Odd.  Are you saying the patch didn't build for you?  It did for
> me, in Thumb mode, and the debug info I saw looked right (no
> thumb bit).
>
>> extern void func_addr() __attribute__ ((alias ("func")));
>> extern void main_addr() __attribute__ ((alias ("main")));
>
> ...
>> but issues remains the same.
>
> That's expected, as the whole point was making a data symbol
> (void *), but that change makes it a function again (thus
> ends up with the thumb bit set again).
>

I am using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
Patch fails to build with following error:

gdb compile failed, ./gdb.dwarf2/dw2-ifort-parameter.c:37:15: error:
'func_addr' alias in between function and variable is not supported
 extern void * func_addr __attribute__ ((alias ("func")));
               ^
./gdb.dwarf2/dw2-ifort-parameter.c:23:1: warning: 'func' aliased
declaration [enabled by default]
 func (void)
 ^
./gdb.dwarf2/dw2-ifort-parameter.c:38:15: error: 'main_addr' alias in
between function and variable is not supported
 extern void * main_addr __attribute__ ((alias ("main")));
               ^
./gdb.dwarf2/dw2-ifort-parameter.c:28:1: warning: 'main' aliased
declaration [enabled by default]
 main (void)
 ^

Re: [PATCH] testsuite/gdb.dwarf2: Fix for dw2-ifort-parameter failure on ARM

[Pedro Alves]

On 01/16/2014 02:16 PM, Omair Javaid wrote:
> On Thu 16 Jan 2014 07:00:37 PM PKT, Pedro Alves wrote:
>> On 01/16/2014 01:55 PM, Omair Javaid wrote:
>>>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>>> index 361c44d..c866b0f 100644
>>>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-ifort-parameter.c
>>>>> @@ -29,3 +29,9 @@ main (void)
>>>>>    func ();
>>>>>    return 0;
>>>>>  }
>>>>> +
>>>>> +/* Addresses represented as data symbols, thus without Thumb (etc.)
>>>>> +   mode bits.  The dw2-ifort-parameter-debug.S file uses this as
>>>>> +   func's low_pc/high_pc.  */
>>>>> +extern void *func_addr __attribute__ ((alias ("func")));
>>>>> +extern void *main_addr __attribute__ ((alias ("main")));
>>> Patch doesnt fix the issue and builds after making changes to alias definition like:
>>
>> Odd.  Are you saying the patch didn't build for you?  It did for
>> me, in Thumb mode, and the debug info I saw looked right (no
>> thumb bit).
>>
>>> extern void func_addr() __attribute__ ((alias ("func")));
>>> extern void main_addr() __attribute__ ((alias ("main")));
>>
>> ...
>>> but issues remains the same.
>>
>> That's expected, as the whole point was making a data symbol
>> (void *), but that change makes it a function again (thus
>> ends up with the thumb bit set again).
>>
> 
> I am using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
> Patch fails to build with following error:
> 
> gdb compile failed, ./gdb.dwarf2/dw2-ifort-parameter.c:37:15: error:
> 'func_addr' alias in between function and variable is not supported
>  extern void * func_addr __attribute__ ((alias ("func")));
>                ^
> ./gdb.dwarf2/dw2-ifort-parameter.c:23:1: warning: 'func' aliased
> declaration [enabled by default]
>  func (void)
>  ^
> ./gdb.dwarf2/dw2-ifort-parameter.c:38:15: error: 'main_addr' alias in
> between function and variable is not supported
>  extern void * main_addr __attribute__ ((alias ("main")));
>                ^
> ./gdb.dwarf2/dw2-ifort-parameter.c:28:1: warning: 'main' aliased
> declaration [enabled by default]
>  main (void)
>  ^

OK.  Well, it seems to me that the root of this whole test's problem
is the exact same as the one being discussed in the
"Fix possible alignment issue with dw2-dir-file-name test case"
thread, for ppc64.  That is, using a function symbol for
the function's low_pc/high_pc range is not OK.  The way we fix
one should fix the other too.

-- 
Pedro Alves