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.
