diff mbox series

[v2,11/11] include/gdbstub: add note to helpers.h

Message ID 20250324102142.67022-12-alex.bennee@linaro.org (mailing list archive)
State New
Headers show
Series gdbstub: conversion to runtime endianess helpers | expand

Commit Message

Alex Bennée March 24, 2025, 10:21 a.m. UTC
We've not yet deprecated but we should steer users away from these
helpers if they want to be in a single/heterogeneous binary.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 include/gdbstub/helpers.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Philippe Mathieu-Daudé March 24, 2025, 4:46 p.m. UTC | #1
On 24/3/25 11:21, Alex Bennée wrote:
> We've not yet deprecated but we should steer users away from these
> helpers if they want to be in a single/heterogeneous binary.

Why not deprecate?

> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   include/gdbstub/helpers.h | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/gdbstub/helpers.h b/include/gdbstub/helpers.h
> index 6f7cc48adc..9b3a535b03 100644
> --- a/include/gdbstub/helpers.h
> +++ b/include/gdbstub/helpers.h
> @@ -2,7 +2,9 @@
>    * gdbstub helpers
>    *
>    * These are all used by the various frontends and have to be host
> - * aware to ensure things are store in target order.
> + * aware to ensure things are store in target order. Consider using
> + * the endian neutral registers.h if you want the architecture to be
> + * included in an eventual single QEMU binary.
>    *
>    * Copyright (c) 2022 Linaro Ltd
>    *
Alex Bennée March 24, 2025, 5:29 p.m. UTC | #2
Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 24/3/25 11:21, Alex Bennée wrote:
>> We've not yet deprecated but we should steer users away from these
>> helpers if they want to be in a single/heterogeneous binary.
>
> Why not deprecate?

I guess philosophically do we expect to eventually convert all frontends
to the new API or only those that want to be in the single binary?
Should I just be more explicit:

>>    *
>>    * These are all used by the various frontends and have to be host
>> - * aware to ensure things are store in target order.
>> + * aware to ensure things are store in target order. Consider using
>> + * the endian neutral registers.h if you want the architecture to be
>> + * included in an eventual single QEMU binary.
>>    *
>>    * Copyright (c) 2022 Linaro Ltd
>>    *


 These are all used by the various frontends and have to be host aware
 to ensure things are store in target order.

 New front-ends should not be using these APIs at all. They should be
 using the endian neutral registers.h as should any architecture that
 intends to be included in an eventual single QEMU binary.
Pierrick Bouvier March 24, 2025, 7:33 p.m. UTC | #3
On 3/24/25 10:29, Alex Bennée wrote:
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 
>> On 24/3/25 11:21, Alex Bennée wrote:
>>> We've not yet deprecated but we should steer users away from these
>>> helpers if they want to be in a single/heterogeneous binary.
>>
>> Why not deprecate?
> 
> I guess philosophically do we expect to eventually convert all frontends
> to the new API or only those that want to be in the single binary?
> Should I just be more explicit:
> 
>>>     *
>>>     * These are all used by the various frontends and have to be host
>>> - * aware to ensure things are store in target order.
>>> + * aware to ensure things are store in target order. Consider using
>>> + * the endian neutral registers.h if you want the architecture to be
>>> + * included in an eventual single QEMU binary.
>>>     *
>>>     * Copyright (c) 2022 Linaro Ltd
>>>     *
> 
> 
>   These are all used by the various frontends and have to be host aware
>   to ensure things are store in target order.
> 

If the fix is an easy "sed like" with static typing guarantee (so no bug 
can be introduced), we can probably just do it on all existing targets, 
and remove this.

If it's hard or error prone, then I would say it's ok to use a "one 
target at a time" approach.

>   New front-ends should not be using these APIs at all. They should be
>   using the endian neutral registers.h as should any architecture that
>   intends to be included in an eventual single QEMU binary.
>
Pierrick Bouvier March 24, 2025, 7:33 p.m. UTC | #4
On 3/24/25 10:29, Alex Bennée wrote:
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 
>> On 24/3/25 11:21, Alex Bennée wrote:
>>> We've not yet deprecated but we should steer users away from these
>>> helpers if they want to be in a single/heterogeneous binary.
>>
>> Why not deprecate?
> 
> I guess philosophically do we expect to eventually convert all frontends
> to the new API or only those that want to be in the single binary?
> Should I just be more explicit:
> 
>>>     *
>>>     * These are all used by the various frontends and have to be host
>>> - * aware to ensure things are store in target order.
>>> + * aware to ensure things are store in target order. Consider using
>>> + * the endian neutral registers.h if you want the architecture to be
>>> + * included in an eventual single QEMU binary.
>>>     *
>>>     * Copyright (c) 2022 Linaro Ltd
>>>     *
> 
> 
>   These are all used by the various frontends and have to be host aware
>   to ensure things are store in target order.
> 

If the fix is an easy "sed like" with static typing guarantee (so no bug 
can be introduced), we can probably just do it on all existing targets, 
and remove this.

If it's hard or error prone, then I would say it's ok to use a "one 
target at a time" approach.

>   New front-ends should not be using these APIs at all. They should be
>   using the endian neutral registers.h as should any architecture that
>   intends to be included in an eventual single QEMU binary.
>
diff mbox series

Patch

diff --git a/include/gdbstub/helpers.h b/include/gdbstub/helpers.h
index 6f7cc48adc..9b3a535b03 100644
--- a/include/gdbstub/helpers.h
+++ b/include/gdbstub/helpers.h
@@ -2,7 +2,9 @@ 
  * gdbstub helpers
  *
  * These are all used by the various frontends and have to be host
- * aware to ensure things are store in target order.
+ * aware to ensure things are store in target order. Consider using
+ * the endian neutral registers.h if you want the architecture to be
+ * included in an eventual single QEMU binary.
  *
  * Copyright (c) 2022 Linaro Ltd
  *