14:14 <palmer> smaeul: ya, that EXPERT thing is on for-next: * bafa451a96d0 - (riscv/for-next, for-next) riscv: defconfig: Remove EXPERT (2 weeks ago) <Joel Stanley>

14:16 <smaeul> palmer: got it, thanks!

14:22 <cousteau> Morning

14:23 <cousteau> How do breakpoints work?  What magic happens when I type `b` in gdb?

14:24 <cousteau> Does gdb tell the target (a RISC-V core, in this case) "hey, whenever you reach memory address 0x12345678, trigger a breakpoint/interrupt and tell me"?

14:26 <palmer> cousteau: for SW breakpoints GDB writes an `ebreak` at the address, for HW breakpoints the trigger registers get used

14:26 <cousteau> Or does it inject a "breakpoint instruction" (I think this is EBREAK) at the point where it wants to insert the interrupt, and then the debug module takes over, does things, and eventually the "debugging machine" tells the core "ok, well done, now execute this instruction that was supposed to be in place of that EBREAK instruction and continue from

14:26 <cousteau> there"?

14:26 <cousteau> palmer: ok, that was what I had sort of figured out but wasn't sure

14:26 <palmer> ya, basically it's either one depending on the mode ;)

14:26 <cousteau> so... what happens when I type `b` in gdb?  HW or SW breakpoint?  Or "it depends"?

14:27 <palmer> ya, it depends

14:27 <palmer> the default is SW breakpoints, because they're basically free

14:27 <cousteau> (stop replying my questions before I ask them!) :)

14:27 <cousteau> I see

14:27 <palmer> but if you're doing something like XIP flash, then GDB is supposed to figure that out and use a HW breakpoint (which really just means telling OpenOCD to set one)

14:28 <cousteau> And I guess there is a limited support for HW breakpoints, because they need to be stored in some sort of CAM and comparisons are expensive

14:28 <cousteau> *limited number of HW breakpoints

14:29 <palmer> Ya, there's a limited number

14:29 <palmer> And in RISC-V they alias with other debug mode triggers

14:29 <cousteau> There could even be zero, and rely 100% on SW breakpoints, right?  And there can be as many SW breakpoints as the gdb program I have installed in my computer can fit into my computer's memory

14:30 <cousteau> ...well, as many as there are instructions in the RV program

14:30 <palmer> Ya, HW breakpoints are optional (and not well supported, they require reaching into debug mode with can get tricky)

14:30 <cousteau> OK, I need to have a look at that thing about debug mode triggers

14:31 <palmer> And yes, you can basically overwrite every instruction with a breakpoint (until you run out of memory for tracking them, or whatever blows up first...)

15:02 <conchuod> seemingly the break is "kbuild: Create intermediate vmlinux build with relocations preserved"

15:04 <palmer> which is ac4f06789b4f ("kbuild: Create intermediate vmlinux build with relocations preserved")

15:08 <conchuod> I'll post on list later, got other stuff to do

17:34 <ganboing> Speaking of HW breakpoints, is it currently supported in linux kernel? I saw some effort last year to utilize SBI debug triggers extension to do that, but looks like no much progress so far?