* [PATCH 1/2] MIPS: jazz: always allow little-endian builds
@ 2021-01-22 11:02 Arnd Bergmann
2021-01-22 11:02 ` [PATCH 2/2] MIPS: make kgdb depend on FPU support Arnd Bergmann
2021-01-22 13:05 ` [PATCH 1/2] MIPS: jazz: always allow little-endian builds Thomas Bogendoerfer
0 siblings, 2 replies; 10+ messages in thread
From: Arnd Bergmann @ 2021-01-22 11:02 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Arnd Bergmann, kernel test robot, Jiaxun Yang, Paul Cercueil,
Paul Burton, linux-mips, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The kernel test robot keeps reporting the same bug when it
shows up in new files after random unrelated patches:
In file included from arch/mips/include/uapi/asm/byteorder.h:13,
from arch/mips/include/asm/bitops.h:20,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/linux/clk.h:13,
from drivers/base/regmap/regmap-mmio.c:7:
include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
8 | #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
| ^~~~~~~
drivers/base/regmap/regmap-mmio.c: In function 'regmap_mmio_gen_context':
>> drivers/base/regmap/regmap-mmio.c:274:2: error: duplicate case value
274 | case REGMAP_ENDIAN_NATIVE:
| ^~~~
drivers/base/regmap/regmap-mmio.c:246:2: note: previously used here
246 | case REGMAP_ENDIAN_NATIVE:
The problem is that some randconfig builds end up on the MIPS jazz
platform with neither CONFIG_CPU_BIG_ENDIAN nor CONFIG_CPU_LITTLE_ENDIAN
because no specific machine is selected. As it turns out, all jazz
machines support little-endian kernels, so this can simply be allowed
globally.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The configuration used by lkp here showed two other unrelated bugs,
one of which I'm addressing in another patch. The one I'm not
addressing is that 32-bit JAZZ with hugepages and 4K pages triggers
BUILD_BUG_ON(IS_ENABLED(CONFIG_32BIT) && (_PFN_SHIFT > PAGE_SHIFT)).
---
arch/mips/Kconfig | 1 +
arch/mips/jazz/Kconfig | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2000bb2b0220..e6bd1eee70f2 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -406,6 +406,7 @@ config MACH_JAZZ
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_100HZ
+ select SYS_SUPPORTS_LITTLE_ENDIAN
help
This a family of machines based on the MIPS R4030 chipset which was
used by several vendors to build RISC/os and Windows NT workstations.
diff --git a/arch/mips/jazz/Kconfig b/arch/mips/jazz/Kconfig
index 06838f80a5d7..42932ca98db9 100644
--- a/arch/mips/jazz/Kconfig
+++ b/arch/mips/jazz/Kconfig
@@ -3,7 +3,6 @@ config ACER_PICA_61
bool "Support for Acer PICA 1 chipset"
depends on MACH_JAZZ
select DMA_NONCOHERENT
- select SYS_SUPPORTS_LITTLE_ENDIAN
help
This is a machine with a R4400 133/150 MHz CPU. To compile a Linux
kernel that runs on these, say Y here. For details about Linux on
@@ -15,7 +14,6 @@ config MIPS_MAGNUM_4000
depends on MACH_JAZZ
select DMA_NONCOHERENT
select SYS_SUPPORTS_BIG_ENDIAN
- select SYS_SUPPORTS_LITTLE_ENDIAN
help
This is a machine with a R4000 100 MHz CPU. To compile a Linux
kernel that runs on these, say Y here. For details about Linux on
@@ -26,7 +24,6 @@ config OLIVETTI_M700
bool "Support for Olivetti M700-10"
depends on MACH_JAZZ
select DMA_NONCOHERENT
- select SYS_SUPPORTS_LITTLE_ENDIAN
help
This is a machine with a R4000 100 MHz CPU. To compile a Linux
kernel that runs on these, say Y here. For details about Linux on
--
2.29.2
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-01-22 11:02 [PATCH 1/2] MIPS: jazz: always allow little-endian builds Arnd Bergmann
@ 2021-01-22 11:02 ` Arnd Bergmann
2021-01-22 13:06 ` Thomas Bogendoerfer
2021-02-08 17:03 ` Maciej W. Rozycki
2021-01-22 13:05 ` [PATCH 1/2] MIPS: jazz: always allow little-endian builds Thomas Bogendoerfer
1 sibling, 2 replies; 10+ messages in thread
From: Arnd Bergmann @ 2021-01-22 11:02 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Arnd Bergmann, kernel test robot, Jiaxun Yang, Paul Cercueil,
Paul Burton, linux-mips, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
kgdb fails to build when the FPU support is disabled:
arch/mips/kernel/kgdb.c: In function 'dbg_set_reg':
arch/mips/kernel/kgdb.c:147:35: error: 'struct thread_struct' has no member named 'fpu'
147 | memcpy((void *)¤t->thread.fpu.fcr31, mem,
| ^
arch/mips/kernel/kgdb.c:155:34: error: 'struct thread_struct' has no member named 'fpu'
155 | memcpy((void *)¤t->thread.fpu.fpr[fp_reg], mem,
This is only relevant for CONFIG_EXPERT=y, so disallowing it
in Kconfig is an easier workaround than fixing it properly.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index e6bd1eee70f2..7fea149f63cf 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -41,7 +41,7 @@ config MIPS
select HANDLE_DOMAIN_IRQ
select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_JUMP_LABEL
- select HAVE_ARCH_KGDB
+ select HAVE_ARCH_KGDB if MIPS_FP_SUPPORT
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
--
2.29.2
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] MIPS: jazz: always allow little-endian builds
2021-01-22 11:02 [PATCH 1/2] MIPS: jazz: always allow little-endian builds Arnd Bergmann
2021-01-22 11:02 ` [PATCH 2/2] MIPS: make kgdb depend on FPU support Arnd Bergmann
@ 2021-01-22 13:05 ` Thomas Bogendoerfer
1 sibling, 0 replies; 10+ messages in thread
From: Thomas Bogendoerfer @ 2021-01-22 13:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, kernel test robot, Jiaxun Yang, Paul Cercueil,
Paul Burton, linux-mips, linux-kernel
On Fri, Jan 22, 2021 at 12:02:50PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The kernel test robot keeps reporting the same bug when it
> shows up in new files after random unrelated patches:
>
> In file included from arch/mips/include/uapi/asm/byteorder.h:13,
> from arch/mips/include/asm/bitops.h:20,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/linux/clk.h:13,
> from drivers/base/regmap/regmap-mmio.c:7:
> include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
> 8 | #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
> | ^~~~~~~
> drivers/base/regmap/regmap-mmio.c: In function 'regmap_mmio_gen_context':
> >> drivers/base/regmap/regmap-mmio.c:274:2: error: duplicate case value
> 274 | case REGMAP_ENDIAN_NATIVE:
> | ^~~~
> drivers/base/regmap/regmap-mmio.c:246:2: note: previously used here
> 246 | case REGMAP_ENDIAN_NATIVE:
>
> The problem is that some randconfig builds end up on the MIPS jazz
> platform with neither CONFIG_CPU_BIG_ENDIAN nor CONFIG_CPU_LITTLE_ENDIAN
> because no specific machine is selected. As it turns out, all jazz
> machines support little-endian kernels, so this can simply be allowed
> globally.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The configuration used by lkp here showed two other unrelated bugs,
> one of which I'm addressing in another patch. The one I'm not
> addressing is that 32-bit JAZZ with hugepages and 4K pages triggers
> BUILD_BUG_ON(IS_ENABLED(CONFIG_32BIT) && (_PFN_SHIFT > PAGE_SHIFT)).
> ---
> arch/mips/Kconfig | 1 +
> arch/mips/jazz/Kconfig | 3 ---
> 2 files changed, 1 insertion(+), 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-01-22 11:02 ` [PATCH 2/2] MIPS: make kgdb depend on FPU support Arnd Bergmann
@ 2021-01-22 13:06 ` Thomas Bogendoerfer
2021-02-08 17:03 ` Maciej W. Rozycki
1 sibling, 0 replies; 10+ messages in thread
From: Thomas Bogendoerfer @ 2021-01-22 13:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, kernel test robot, Jiaxun Yang, Paul Cercueil,
Paul Burton, linux-mips, linux-kernel
On Fri, Jan 22, 2021 at 12:02:51PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> kgdb fails to build when the FPU support is disabled:
>
> arch/mips/kernel/kgdb.c: In function 'dbg_set_reg':
> arch/mips/kernel/kgdb.c:147:35: error: 'struct thread_struct' has no member named 'fpu'
> 147 | memcpy((void *)¤t->thread.fpu.fcr31, mem,
> | ^
> arch/mips/kernel/kgdb.c:155:34: error: 'struct thread_struct' has no member named 'fpu'
> 155 | memcpy((void *)¤t->thread.fpu.fpr[fp_reg], mem,
>
> This is only relevant for CONFIG_EXPERT=y, so disallowing it
> in Kconfig is an easier workaround than fixing it properly.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-01-22 11:02 ` [PATCH 2/2] MIPS: make kgdb depend on FPU support Arnd Bergmann
2021-01-22 13:06 ` Thomas Bogendoerfer
@ 2021-02-08 17:03 ` Maciej W. Rozycki
2021-02-10 11:38 ` Daniel Thompson
1 sibling, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2021-02-08 17:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Thomas Bogendoerfer, Arnd Bergmann, kernel test robot,
Jiaxun Yang, Paul Cercueil, Paul Burton, linux-mips,
linux-kernel
On Fri, 22 Jan 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> kgdb fails to build when the FPU support is disabled:
>
> arch/mips/kernel/kgdb.c: In function 'dbg_set_reg':
> arch/mips/kernel/kgdb.c:147:35: error: 'struct thread_struct' has no member named 'fpu'
> 147 | memcpy((void *)¤t->thread.fpu.fcr31, mem,
> | ^
> arch/mips/kernel/kgdb.c:155:34: error: 'struct thread_struct' has no member named 'fpu'
> 155 | memcpy((void *)¤t->thread.fpu.fpr[fp_reg], mem,
>
> This is only relevant for CONFIG_EXPERT=y, so disallowing it
> in Kconfig is an easier workaround than fixing it properly.
Wrapping the relevant parts of this file into #ifdef MIPS_FP_SUPPORT
would be as easy though and would qualify as a proper fix given that we
have no XML description support for the MIPS target (so we need to supply
the inexistent registers in the protocol; or maybe we can return NULL in
`dbg_get_reg' to get them padded out in the RSP packet, I haven't checked
if generic KGDB code supports this feature).
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-02-08 17:03 ` Maciej W. Rozycki
@ 2021-02-10 11:38 ` Daniel Thompson
2021-02-10 12:11 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thompson @ 2021-02-10 11:38 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Arnd Bergmann, Thomas Bogendoerfer, Arnd Bergmann,
kernel test robot, Jiaxun Yang, Paul Cercueil, Paul Burton,
linux-mips, linux-kernel
On Mon, Feb 08, 2021 at 06:03:08PM +0100, Maciej W. Rozycki wrote:
> On Fri, 22 Jan 2021, Arnd Bergmann wrote:
>
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > kgdb fails to build when the FPU support is disabled:
> >
> > arch/mips/kernel/kgdb.c: In function 'dbg_set_reg':
> > arch/mips/kernel/kgdb.c:147:35: error: 'struct thread_struct' has no member named 'fpu'
> > 147 | memcpy((void *)¤t->thread.fpu.fcr31, mem,
> > | ^
> > arch/mips/kernel/kgdb.c:155:34: error: 'struct thread_struct' has no member named 'fpu'
> > 155 | memcpy((void *)¤t->thread.fpu.fpr[fp_reg], mem,
> >
> > This is only relevant for CONFIG_EXPERT=y, so disallowing it
> > in Kconfig is an easier workaround than fixing it properly.
>
> Wrapping the relevant parts of this file into #ifdef MIPS_FP_SUPPORT
> would be as easy though and would qualify as a proper fix given that we
> have no XML description support for the MIPS target (so we need to supply
> the inexistent registers in the protocol; or maybe we can return NULL in
> `dbg_get_reg' to get them padded out in the RSP packet, I haven't checked
> if generic KGDB code supports this feature).
Returning NULL should be fine.
The generic code will cope OK. The values in the f.p. registers may
act a little odd if gdb uses a 'G' packet to set them to non-zero values
(since kgdb will cache the values gdb sent it) but the developer
operating the debugger will probably figure out what is going on without
too much pain.
Daniel.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-02-10 11:38 ` Daniel Thompson
@ 2021-02-10 12:11 ` Maciej W. Rozycki
2021-02-10 12:29 ` Daniel Thompson
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2021-02-10 12:11 UTC (permalink / raw)
To: Daniel Thompson
Cc: Arnd Bergmann, Thomas Bogendoerfer, Arnd Bergmann,
kernel test robot, Jiaxun Yang, Paul Cercueil, Paul Burton,
linux-mips, linux-kernel
On Wed, 10 Feb 2021, Daniel Thompson wrote:
> > Wrapping the relevant parts of this file into #ifdef MIPS_FP_SUPPORT
> > would be as easy though and would qualify as a proper fix given that we
> > have no XML description support for the MIPS target (so we need to supply
> > the inexistent registers in the protocol; or maybe we can return NULL in
> > `dbg_get_reg' to get them padded out in the RSP packet, I haven't checked
> > if generic KGDB code supports this feature).
>
> Returning NULL should be fine.
>
> The generic code will cope OK. The values in the f.p. registers may
> act a little odd if gdb uses a 'G' packet to set them to non-zero values
> (since kgdb will cache the values gdb sent it) but the developer
> operating the debugger will probably figure out what is going on without
> too much pain.
Ack, thanks!
NB if GDB sees a register padded out (FAOD it means all-x's rather than a
hex string placed throughout the respective slot) in a `g' packet, then it
will mark the register internally as "unavailable" and present it to the
receiver of the information as such rather than giving any specific value.
I don't remember offhand what the syntax for the `G' packet is in that
case; possibly GDB just sends all-zeros, and in any case you can't make
GDB write any specific value to such a register via any user interface.
The way the unavailability is shown depends on the interface used, i.e.
it will be different between the `info all-registers'/`info register $reg'
commands, and the `p $reg' command (or any expression involving `$reg'),
and the MI interface. But in any case it will be unambiguous.
In no case however there will be user confusion for such registers.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-02-10 12:11 ` Maciej W. Rozycki
@ 2021-02-10 12:29 ` Daniel Thompson
2021-02-10 14:15 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thompson @ 2021-02-10 12:29 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Arnd Bergmann, Thomas Bogendoerfer, Arnd Bergmann,
kernel test robot, Jiaxun Yang, Paul Cercueil, Paul Burton,
linux-mips, linux-kernel
On Wed, Feb 10, 2021 at 01:11:28PM +0100, Maciej W. Rozycki wrote:
> On Wed, 10 Feb 2021, Daniel Thompson wrote:
>
> > > Wrapping the relevant parts of this file into #ifdef MIPS_FP_SUPPORT
> > > would be as easy though and would qualify as a proper fix given that we
> > > have no XML description support for the MIPS target (so we need to supply
> > > the inexistent registers in the protocol; or maybe we can return NULL in
> > > `dbg_get_reg' to get them padded out in the RSP packet, I haven't checked
> > > if generic KGDB code supports this feature).
> >
> > Returning NULL should be fine.
> >
> > The generic code will cope OK. The values in the f.p. registers may
> > act a little odd if gdb uses a 'G' packet to set them to non-zero values
> > (since kgdb will cache the values gdb sent it) but the developer
> > operating the debugger will probably figure out what is going on without
> > too much pain.
>
> Ack, thanks!
>
> NB if GDB sees a register padded out (FAOD it means all-x's rather than a
> hex string placed throughout the respective slot) in a `g' packet, then it
> will mark the register internally as "unavailable" and present it to the
> receiver of the information as such rather than giving any specific value.
> I don't remember offhand what the syntax for the `G' packet is in that
> case; possibly GDB just sends all-zeros, and in any case you can't make
> GDB write any specific value to such a register via any user
> interface.
kgdb doesn't track register validity and adding would be a fairly big
change. Everything internally (including some of the interactions with
arch code) is based on updating a binary shadow of register state which
is only bin2hex'ed just before transmitting a packet.
It will simply default them to zero and update them on a 'G' packet.
> The way the unavailability is shown depends on the interface used, i.e.
> it will be different between the `info all-registers'/`info register $reg'
> commands, and the `p $reg' command (or any expression involving `$reg'),
> and the MI interface. But in any case it will be unambiguous.
I guess this probably does create a technical protocol violation since
kgdb will reject per-register read/write for register that its report
says are zero rather then invalid.
Daniel.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-02-10 12:29 ` Daniel Thompson
@ 2021-02-10 14:15 ` Maciej W. Rozycki
2021-02-10 17:05 ` Daniel Thompson
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2021-02-10 14:15 UTC (permalink / raw)
To: Daniel Thompson
Cc: Arnd Bergmann, Thomas Bogendoerfer, Arnd Bergmann,
kernel test robot, Jiaxun Yang, Paul Cercueil, Paul Burton,
linux-mips, linux-kernel
On Wed, 10 Feb 2021, Daniel Thompson wrote:
> > NB if GDB sees a register padded out (FAOD it means all-x's rather than a
> > hex string placed throughout the respective slot) in a `g' packet, then it
> > will mark the register internally as "unavailable" and present it to the
> > receiver of the information as such rather than giving any specific value.
> > I don't remember offhand what the syntax for the `G' packet is in that
> > case; possibly GDB just sends all-zeros, and in any case you can't make
> > GDB write any specific value to such a register via any user
> > interface.
>
> kgdb doesn't track register validity and adding would be a fairly big
> change. Everything internally (including some of the interactions with
> arch code) is based on updating a binary shadow of register state which
> is only bin2hex'ed just before transmitting a packet.
I've had a peek and it doesn't appear to me it would be a big deal.
We have `gdb_regs' defined as an array of longs. We'd just need a second
array for a register validity bitmap, which could for simplicity just have
a single bit per each byte of `gdb_regs'. It would then be updated in
`pt_regs_to_gdb_regs' according to the result of `dbg_get_reg' across the
number of bits given by `dbg_reg_def[i].size'. And then `kgdb_mem2hex'
would interpret the bitmap given as an extra argument accordingly.
It looks to me like a couple of lines of extra code really.
> It will simply default them to zero and update them on a 'G' packet.
Ack.
> > The way the unavailability is shown depends on the interface used, i.e.
> > it will be different between the `info all-registers'/`info register $reg'
> > commands, and the `p $reg' command (or any expression involving `$reg'),
> > and the MI interface. But in any case it will be unambiguous.
>
> I guess this probably does create a technical protocol violation since
> kgdb will reject per-register read/write for register that its report
> says are zero rather then invalid.
Not a violation, as GDB won't ever issue a `p'/`P' packet for a register
that is in the range covered by `g'/`G'. This is by design. I'd have to
track down the justification, but this is the right thing really.
Also there is no issue with returning a rubbish value written with `G',
as the same already happens with any RSP debug stub (or for that matter
native GDB target) that deals with read-only registers. If you attempt to
write one, then all the caches will keep the new value, and you will often
have to make the target resume execution before the value reported is
reset to the hardwired one.
Debug stubs often cache registers for performance reasons, and may not
even write them out unless execution is to be resumed, which often has
serious consequences if a write to a hardware registers has side effects.
For example I had that with an Intel Atom CPU switching between the real
and the protected mode with a CR0 register write issued via a debug probe
wired through the JTAG inteface.
Caching is surely what Linux `gdbserver' does, as is what all JTAG debug
interfaces do that I have come across, as JTAG access is usually painfully
slow. Therefore in many cases GDB's `flushregs' command won't help as the
stub will happily resend what it has previously cached with any updates
applied locally only.
FWIW,
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support
2021-02-10 14:15 ` Maciej W. Rozycki
@ 2021-02-10 17:05 ` Daniel Thompson
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Thompson @ 2021-02-10 17:05 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Arnd Bergmann, Thomas Bogendoerfer, Arnd Bergmann,
kernel test robot, Jiaxun Yang, Paul Cercueil, Paul Burton,
linux-mips, linux-kernel
On Wed, Feb 10, 2021 at 03:15:10PM +0100, Maciej W. Rozycki wrote:
> On Wed, 10 Feb 2021, Daniel Thompson wrote:
>
> > > NB if GDB sees a register padded out (FAOD it means all-x's rather than a
> > > hex string placed throughout the respective slot) in a `g' packet, then it
> > > will mark the register internally as "unavailable" and present it to the
> > > receiver of the information as such rather than giving any specific value.
> > > I don't remember offhand what the syntax for the `G' packet is in that
> > > case; possibly GDB just sends all-zeros, and in any case you can't make
> > > GDB write any specific value to such a register via any user
> > > interface.
> >
> > kgdb doesn't track register validity and adding would be a fairly big
> > change. Everything internally (including some of the interactions with
> > arch code) is based on updating a binary shadow of register state which
> > is only bin2hex'ed just before transmitting a packet.
>
> I've had a peek and it doesn't appear to me it would be a big deal.
>
> We have `gdb_regs' defined as an array of longs. We'd just need a second
> array for a register validity bitmap, which could for simplicity just have
> a single bit per each byte of `gdb_regs'. It would then be updated in
> `pt_regs_to_gdb_regs' according to the result of `dbg_get_reg' across the
> number of bits given by `dbg_reg_def[i].size'. And then `kgdb_mem2hex'
> would interpret the bitmap given as an extra argument accordingly.
>
> It looks to me like a couple of lines of extra code really.
Agree, the core changes aren't too bad.
I was more concerned about whether the validity bits would leak into the
arch specific code via sleeping_thread_to_gdb_regs() and also noted the
effort needed to review each architectures dbg_get_reg() implementation
if we are going to react differently to it's return value.
It is still not an infeasible amount of work though if someone
does want to go in this direction.
Daniel.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-02-10 17:06 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-22 11:02 [PATCH 1/2] MIPS: jazz: always allow little-endian builds Arnd Bergmann
2021-01-22 11:02 ` [PATCH 2/2] MIPS: make kgdb depend on FPU support Arnd Bergmann
2021-01-22 13:06 ` Thomas Bogendoerfer
2021-02-08 17:03 ` Maciej W. Rozycki
2021-02-10 11:38 ` Daniel Thompson
2021-02-10 12:11 ` Maciej W. Rozycki
2021-02-10 12:29 ` Daniel Thompson
2021-02-10 14:15 ` Maciej W. Rozycki
2021-02-10 17:05 ` Daniel Thompson
2021-01-22 13:05 ` [PATCH 1/2] MIPS: jazz: always allow little-endian builds Thomas Bogendoerfer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.