On 28 February 2016 at 17:34, Martin Pieuchot <[email protected]> wrote: > On 28/02/16(Sun) 17:02, Mike Belopuhov wrote: >> On 28 February 2016 at 14:38, Martin Pieuchot <[email protected]> wrote: >> > In order to dynamically instrument kernel functions, I plan to add >> > breakpoints where a probe needs to be executed. Trap handlers will >> > be modified to check if the address of the trapping instruction >> > correspond to a registered probe, and if that's the case, the kernel >> > will execute the associated code. >> > >> > While implementing such mechanism for amd64 and i386, I discovered >> > some differences in the existing code that only history seems to justify. >> > >> > So the diff below get rids of the BPTTRAP() and other small differences >> > around 'calltrap' for these architectures. In particular interrupts >> > are now enabled unconditionally on i386 before entering trap(). Any >> > counter indication for doing so? >> > >> >> That 'sti' that you're adding might have side effects, but I can't think of >> any >> bad ones. You'll get some funny 'sti', 'sti' sequences though since some >> of the callers do 'sti' themselves (e.g resume_iret). >> >> > I wonder if I should split i386's locore.s to match amd64's vector.S... >> > >> >> Technically i386 has apicvec.s which is what vectror.S on amd64 >> since the arch is specified to always have an APIC. Splitting it into >> trap.S is another possibility, but I'm not sure it's worth it. Possibly >> moving actual APIC vector stubs to C is a better plan and then >> vector.s will be up for the grabs. >> >> > Comments, ok? >> > >> >> Honestly, I'd like the alltraps/sti bit to be handled separately even >> if it's just for the purpose of sync'ing up two implementations. > > Something like that first? >
Yes. It's a tiny bit ugly, but you know how to clean it up already, so you should go ahead with this. OK mikeb
