Hi, On Mon, Dec 19, 2022 at 2:11 PM Helge Deller <del...@gmx.de> wrote: > > On my 32-bit machine, with BREAK_INSTR_SIZE=4 the kgdb_break[] structure > allocates 16000 bytes of static kernel memory, which is - by default - > to be able to handle up to 1000 concurrent kgdb breakpoints. I might be > wrong, but I doubt that in real life someone really needs that many > breakpoints, so I suggest to reduce the number of possible kgdb > breakpoints and thus reduce the memory footprint of kgdb_break[]. > > Signed-off-by: Helge Deller <del...@gmx.de> > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index 258cdde8d356..fab81c4f007e 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -95,7 +95,7 @@ extern char *dbg_get_reg(int regno, void *mem, struct > pt_regs *regs); > extern int dbg_set_reg(int regno, void *mem, struct pt_regs *regs); > #endif > #ifndef KGDB_MAX_BREAKPOINTS > -# define KGDB_MAX_BREAKPOINTS 1000 > +# define KGDB_MAX_BREAKPOINTS 40
My first instinct is that, while I agree that 1000 feels too much, that maybe 40 would have been slightly too small? I could almost imagine myself using that many breakpoints while stepping through code. ...but then again, I guess I'd say that Linux doesn't really behave that great at having its code stepped through with a debugger anyway. While it can work OK, it's not something where I'd expect people to regularly have super long debugging sessions with lots of breakpoints set and constantly dropping into the debugger and then continuing. So I guess in the end, I'd be OK with limiting it to 40. Thus: Reviewed-by: Douglas Anderson <diand...@chromium.org> _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
