[PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Luis Machado]

When we want to fetch tags from a memory range, the last address in that
range is not included.

There is a off-by-one error in aarch64_mte_get_tag_granules, which this
patch fixes.

gdb/ChangeLog:

YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>

	* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
	include the last address in the range.
---
 gdb/arch/aarch64-mte-linux.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
index 959c0247ed5..7c2ae9a7058 100644
--- a/gdb/arch/aarch64-mte-linux.c
+++ b/gdb/arch/aarch64-mte-linux.c
@@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
   /* Start address */
   CORE_ADDR s_addr = align_down (addr, granule_size);
   /* End address */
-  CORE_ADDR e_addr = align_down (addr + len, granule_size);
+  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);
 
-  /* We always have at least 1 granule.  */
+  /* We always have at least 1 granule because len is non-zero at this
+     point.  */
   return 1 + (e_addr - s_addr) / granule_size;
 }
 
-- 
2.25.1

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Alan Hayward]

> On 11 May 2021, at 14:20, Luis Machado via Gdb-patches <gdb-patches@sourceware.org> wrote:
> 
> When we want to fetch tags from a memory range, the last address in that
> range is not included.
> 
> There is a off-by-one error in aarch64_mte_get_tag_granules, which this
> patch fixes.
> 
> gdb/ChangeLog:
> 
> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
> 
> 	* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
> 	include the last address in the range.
> ---
> gdb/arch/aarch64-mte-linux.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
> index 959c0247ed5..7c2ae9a7058 100644
> --- a/gdb/arch/aarch64-mte-linux.c
> +++ b/gdb/arch/aarch64-mte-linux.c
> @@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
>   /* Start address */
>   CORE_ADDR s_addr = align_down (addr, granule_size);
>   /* End address */
> -  CORE_ADDR e_addr = align_down (addr + len, granule_size);
> +  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);
> 
> -  /* We always have at least 1 granule.  */
> +  /* We always have at least 1 granule because len is non-zero at this
> +     point.  */
>   return 1 + (e_addr - s_addr) / granule_size;

Ok,  I’m happy with round down because we never want to read/write a partial tag

But if len is greater than zero, but less than the size of a one tag, then it returns 1. Is that correct?
Should it instead be:
  if (len < granule_size)
    return 0;

> }
> 
> -- 
> 2.25.1
> 

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Alan Hayward]

On 11 May 2021, at 14:20, Luis Machado via Gdb-patches <gdb-patches@sourceware.org<mailto:gdb-patches@sourceware.org>> wrote:

When we want to fetch tags from a memory range, the last address in that
range is not included.

There is a off-by-one error in aarch64_mte_get_tag_granules, which this
patch fixes.

gdb/ChangeLog:

YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org<mailto:luis.machado@linaro.org>>

* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
include the last address in the range.
---
gdb/arch/aarch64-mte-linux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
index 959c0247ed5..7c2ae9a7058 100644
--- a/gdb/arch/aarch64-mte-linux.c
+++ b/gdb/arch/aarch64-mte-linux.c
@@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
 /* Start address */
 CORE_ADDR s_addr = align_down (addr, granule_size);
 /* End address */
-  CORE_ADDR e_addr = align_down (addr + len, granule_size);
+  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);

-  /* We always have at least 1 granule.  */
+  /* We always have at least 1 granule because len is non-zero at this
+     point.  */
 return 1 + (e_addr - s_addr) / granule_size;

Ok,  I’m happy with round down because we never want to read/write a partial tag

But if len is greater than zero, but less than the size of a one tag, then it returns 1. Is that correct?
Should it instead be:
 if (len < granule_size)
   return 0;

}

--
2.25.1

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Luis Machado]

On 5/13/21 7:50 AM, Alan Hayward wrote:
> 
> 
>> On 11 May 2021, at 14:20, Luis Machado via Gdb-patches <gdb-patches@sourceware.org> wrote:
>>
>> When we want to fetch tags from a memory range, the last address in that
>> range is not included.
>>
>> There is a off-by-one error in aarch64_mte_get_tag_granules, which this
>> patch fixes.
>>
>> gdb/ChangeLog:
>>
>> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
>>
>> 	* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
>> 	include the last address in the range.
>> ---
>> gdb/arch/aarch64-mte-linux.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
>> index 959c0247ed5..7c2ae9a7058 100644
>> --- a/gdb/arch/aarch64-mte-linux.c
>> +++ b/gdb/arch/aarch64-mte-linux.c
>> @@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
>>    /* Start address */
>>    CORE_ADDR s_addr = align_down (addr, granule_size);
>>    /* End address */
>> -  CORE_ADDR e_addr = align_down (addr + len, granule_size);
>> +  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);
>>
>> -  /* We always have at least 1 granule.  */
>> +  /* We always have at least 1 granule because len is non-zero at this
>> +     point.  */
>>    return 1 + (e_addr - s_addr) / granule_size;
> 
> Ok,  I’m happy with round down because we never want to read/write a partial tag
> 
> But if len is greater than zero, but less than the size of a one tag, then it returns 1. Is that correct?

The range is specified by [address, address + len). If len is non-zero, 
we will always have a non-empty range and therefore will always have tag 
granules.

> Should it instead be:
>    if (len < granule_size)
>      return 0;

We want to know how many tag granules exist in a particular range. We 
only get 0 granules if the range is empty.

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Alan Hayward]

On 13 May 2021, at 11:56, Luis Machado <luis.machado@linaro.org<mailto:luis.machado@linaro.org>> wrote:

On 5/13/21 7:50 AM, Alan Hayward wrote:
On 11 May 2021, at 14:20, Luis Machado via Gdb-patches <gdb-patches@sourceware.org<mailto:gdb-patches@sourceware.org>> wrote:

When we want to fetch tags from a memory range, the last address in that
range is not included.

There is a off-by-one error in aarch64_mte_get_tag_granules, which this
patch fixes.

gdb/ChangeLog:

YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org<mailto:luis.machado@linaro.org>>

* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
include the last address in the range.
---
gdb/arch/aarch64-mte-linux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
index 959c0247ed5..7c2ae9a7058 100644
--- a/gdb/arch/aarch64-mte-linux.c
+++ b/gdb/arch/aarch64-mte-linux.c
@@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
  /* Start address */
  CORE_ADDR s_addr = align_down (addr, granule_size);
  /* End address */
-  CORE_ADDR e_addr = align_down (addr + len, granule_size);
+  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);

-  /* We always have at least 1 granule.  */
+  /* We always have at least 1 granule because len is non-zero at this
+     point.  */
  return 1 + (e_addr - s_addr) / granule_size;
Ok,  I’m happy with round down because we never want to read/write a partial tag
But if len is greater than zero, but less than the size of a one tag, then it returns 1. Is that correct?

The range is specified by [address, address + len). If len is non-zero, we will always have a non-empty range and therefore will always have tag granules.

Should it instead be:
  if (len < granule_size)
    return 0;

We want to know how many tag granules exist in a particular range. We only get 0 granules if the range is empty.

Assuming addr is aligned, then calculating length -> return value
3 * granulesize -> 3
2.5 * granulesize -> 2
2 * granulesize -> 2
1.5 * granulesize -> 1
1 * granulesize -> 1
0.5 * granulesize -> 1.   - this doesn’t match the others.
0 -> 0

?

Alan.

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Luis Machado]

On 5/13/21 8:24 AM, Alan Hayward wrote:
> 
> 
>> On 13 May 2021, at 11:56, Luis Machado <luis.machado@linaro.org 
>> <mailto:luis.machado@linaro.org>> wrote:
>>
>> On 5/13/21 7:50 AM, Alan Hayward wrote:
>>>> On 11 May 2021, at 14:20, Luis Machado via Gdb-patches 
>>>> <gdb-patches@sourceware.org <mailto:gdb-patches@sourceware.org>> wrote:
>>>>
>>>> When we want to fetch tags from a memory range, the last address in that
>>>> range is not included.
>>>>
>>>> There is a off-by-one error in aarch64_mte_get_tag_granules, which this
>>>> patch fixes.
>>>>
>>>> gdb/ChangeLog:
>>>>
>>>> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org 
>>>> <mailto:luis.machado@linaro.org>>
>>>>
>>>> * arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
>>>> include the last address in the range.
>>>> ---
>>>> gdb/arch/aarch64-mte-linux.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
>>>> index 959c0247ed5..7c2ae9a7058 100644
>>>> --- a/gdb/arch/aarch64-mte-linux.c
>>>> +++ b/gdb/arch/aarch64-mte-linux.c
>>>> @@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, 
>>>> size_t len, size_t granule_size)
>>>>   /* Start address */
>>>>   CORE_ADDR s_addr = align_down (addr, granule_size);
>>>>   /* End address */
>>>> -  CORE_ADDR e_addr = align_down (addr + len, granule_size);
>>>> +  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);
>>>>
>>>> -  /* We always have at least 1 granule.  */
>>>> +  /* We always have at least 1 granule because len is non-zero at this
>>>> +     point.  */
>>>>   return 1 + (e_addr - s_addr) / granule_size;
>>> Ok,  I’m happy with round down because we never want to read/write a 
>>> partial tag
>>> But if len is greater than zero, but less than the size of a one tag, 
>>> then it returns 1. Is that correct?
>>
>> The range is specified by [address, address + len). If len is 
>> non-zero, we will always have a non-empty range and therefore will 
>> always have tag granules.
>>
>>> Should it instead be:
>>>   if (len < granule_size)
>>>     return 0;
>>
>> We want to know how many tag granules exist in a particular range. We 
>> only get 0 granules if the range is empty.
> 
> Assuming addr is aligned, then calculating length -> return value > 3 * granulesize -> 3
> 2.5 * granulesize -> 2
> 2 * granulesize -> 2
> 1.5 * granulesize -> 1
> 1 * granulesize -> 1
> 0.5 * granulesize -> 1.   - this doesn’t match the others.
> 0 -> 0

Sorry. I'm not following. Assuming addr is aligned to the granule size, 
we'd have the following length -> granules mapping:

0 -> 0
1 -> 1 granule
2 -> 1 granule
3 -> 1 granule
...
15 -> 1 granule
16 -> 2 granules
17 -> 2 granules
... and so on.

> 
> ?
> 
> Alan.
> 
> 
> 
> 

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Alan Hayward]

On 13 May 2021, at 12:50, Luis Machado <luis.machado@linaro.org<mailto:luis.machado@linaro.org>> wrote:

On 5/13/21 8:24 AM, Alan Hayward wrote:
On 13 May 2021, at 11:56, Luis Machado <luis.machado@linaro.org<mailto:luis.machado@linaro.org><mailto:luis.machado@linaro.org>> wrote:

On 5/13/21 7:50 AM, Alan Hayward wrote:
On 11 May 2021, at 14:20, Luis Machado via Gdb-patches <gdb-patches@sourceware.org<mailto:gdb-patches@sourceware.org> <mailto:gdb-patches@sourceware.org>> wrote:

When we want to fetch tags from a memory range, the last address in that
range is not included.

There is a off-by-one error in aarch64_mte_get_tag_granules, which this
patch fixes.

gdb/ChangeLog:

YYYY-MM-DD  Luis Machado <luis.machado@linaro.org<mailto:luis.machado@linaro.org><mailto:luis.machado@linaro.org>>

* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
include the last address in the range.
---
gdb/arch/aarch64-mte-linux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/arch/aarch64-mte-linux.c b/gdb/arch/aarch64-mte-linux.c
index 959c0247ed5..7c2ae9a7058 100644
--- a/gdb/arch/aarch64-mte-linux.c
+++ b/gdb/arch/aarch64-mte-linux.c
@@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size)
  /* Start address */
  CORE_ADDR s_addr = align_down (addr, granule_size);
  /* End address */
-  CORE_ADDR e_addr = align_down (addr + len, granule_size);
+  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);

-  /* We always have at least 1 granule.  */
+  /* We always have at least 1 granule because len is non-zero at this
+     point.  */
  return 1 + (e_addr - s_addr) / granule_size;
Ok,  I’m happy with round down because we never want to read/write a partial tag
But if len is greater than zero, but less than the size of a one tag, then it returns 1. Is that correct?

The range is specified by [address, address + len). If len is non-zero, we will always have a non-empty range and therefore will always have tag granules.

Should it instead be:
  if (len < granule_size)
    return 0;

We want to know how many tag granules exist in a particular range. We only get 0 granules if the range is empty.
Assuming addr is aligned, then calculating length -> return value > 3 * granulesize -> 3
2.5 * granulesize -> 2
2 * granulesize -> 2
1.5 * granulesize -> 1
1 * granulesize -> 1
0.5 * granulesize -> 1.   - this doesn’t match the others.
0 -> 0

Sorry. I'm not following. Assuming addr is aligned to the granule size, we'd have the following length -> granules mapping:

0 -> 0
1 -> 1 granule
2 -> 1 granule
3 -> 1 granule
...
15 -> 1 granule
16 -> 2 granules
17 -> 2 granules
... and so on.


Right, I was getting confused. It's rounding up to the next whole granule (whilst ensuring min value of 1). Need more coffee.

Ok, looks good to me :)

Alan.

Re: [PATCH] [GDB,AArch64] Fix off-by-one when calculating tag granules.

[Luis Machado]

On 5/13/21 9:59 AM, Alan Hayward wrote:
> 
> 
>> On 13 May 2021, at 12:50, Luis Machado <luis.machado@linaro.org 
>> <mailto:luis.machado@linaro.org>> wrote:
>>
>> On 5/13/21 8:24 AM, Alan Hayward wrote:
>>>> On 13 May 2021, at 11:56, Luis Machado <luis.machado@linaro.org 
>>>> <mailto:luis.machado@linaro.org><mailto:luis.machado@linaro.org 
>>>> <mailto:luis.machado@linaro.org>>> wrote:
>>>>
>>>> On 5/13/21 7:50 AM, Alan Hayward wrote:
>>>>>> On 11 May 2021, at 14:20, Luis Machado via Gdb-patches 
>>>>>> <gdb-patches@sourceware.org 
>>>>>> <mailto:gdb-patches@sourceware.org><mailto:gdb-patches@sourceware.org 
>>>>>> <mailto:gdb-patches@sourceware.org>>> wrote:
>>>>>>
>>>>>> When we want to fetch tags from a memory range, the last address 
>>>>>> in that
>>>>>> range is not included.
>>>>>>
>>>>>> There is a off-by-one error in aarch64_mte_get_tag_granules, which 
>>>>>> this
>>>>>> patch fixes.
>>>>>>
>>>>>> gdb/ChangeLog:
>>>>>>
>>>>>> YYYY-MM-DD  Luis Machado <luis.machado@linaro.org 
>>>>>> <mailto:luis.machado@linaro.org><mailto:luis.machado@linaro.org 
>>>>>> <mailto:luis.machado@linaro.org>>>
>>>>>>
>>>>>> * arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
>>>>>> include the last address in the range.
>>>>>> ---
>>>>>> gdb/arch/aarch64-mte-linux.c | 5 +++--
>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/gdb/arch/aarch64-mte-linux.c 
>>>>>> b/gdb/arch/aarch64-mte-linux.c
>>>>>> index 959c0247ed5..7c2ae9a7058 100644
>>>>>> --- a/gdb/arch/aarch64-mte-linux.c
>>>>>> +++ b/gdb/arch/aarch64-mte-linux.c
>>>>>> @@ -31,9 +31,10 @@ aarch64_mte_get_tag_granules (CORE_ADDR addr, 
>>>>>> size_t len, size_t granule_size)
>>>>>>   /* Start address */
>>>>>>   CORE_ADDR s_addr = align_down (addr, granule_size);
>>>>>>   /* End address */
>>>>>> -  CORE_ADDR e_addr = align_down (addr + len, granule_size);
>>>>>> +  CORE_ADDR e_addr = align_down (addr + len - 1, granule_size);
>>>>>>
>>>>>> -  /* We always have at least 1 granule.  */
>>>>>> +  /* We always have at least 1 granule because len is non-zero at 
>>>>>> this
>>>>>> +     point.  */
>>>>>>   return 1 + (e_addr - s_addr) / granule_size;
>>>>> Ok,  I’m happy with round down because we never want to read/write 
>>>>> a partial tag
>>>>> But if len is greater than zero, but less than the size of a one 
>>>>> tag, then it returns 1. Is that correct?
>>>>
>>>> The range is specified by [address, address + len). If len is 
>>>> non-zero, we will always have a non-empty range and therefore will 
>>>> always have tag granules.
>>>>
>>>>> Should it instead be:
>>>>>   if (len < granule_size)
>>>>>     return 0;
>>>>
>>>> We want to know how many tag granules exist in a particular range. 
>>>> We only get 0 granules if the range is empty.
>>> Assuming addr is aligned, then calculating length -> return value > 3 
>>> * granulesize -> 3
>>> 2.5 * granulesize -> 2
>>> 2 * granulesize -> 2
>>> 1.5 * granulesize -> 1
>>> 1 * granulesize -> 1
>>> 0.5 * granulesize -> 1.   - this doesn’t match the others.
>>> 0 -> 0
>>
>> Sorry. I'm not following. Assuming addr is aligned to the granule 
>> size, we'd have the following length -> granules mapping:
>>
>> 0 -> 0
>> 1 -> 1 granule
>> 2 -> 1 granule
>> 3 -> 1 granule
>> ...
>> 15 -> 1 granule
>> 16 -> 2 granules
>> 17 -> 2 granules
>> ... and so on.
>>
> 
> Right, I was getting confused. It's rounding up to the next whole 
> granule (whilst ensuring min value of 1). Need more coffee.
> 
> Ok, looks good to me :)

Thanks! :-)

Pushed now.