| Message ID | 20250324102142.67022-12-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | gdbstub: conversion to runtime endianess helpers | expand |
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 > *
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.
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. >
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 --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 *
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(-)