re: CVS commit: src/sys/arch
"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Fri Aug 18 10:28:53 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: kern.ldscript > src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB > > Log Message: > Fill the .text padding with 0xcc (int3), in such a way that any jump into > this area will automatically fault. The alignment within the section is > necessary, in order to fill strictly all of the padding (took me a while > to figure this out); but it does not change the kernel size. > > Greatly inspired from FreeBSD, but for some reason they decided not to > apply the alignment. it's really a pity that we have almost _2MB_ of basically wasted space in the kernel. there's really no good reason for it. it's not as if ELF files are incapable of expressing discontiguous sections separately without zero or other filling. the int3 filling could be done at run time. you didn't introduce this issue, but you did add 1MB of wastage a while back now. can you please look at fixing this? it both slows boot and fills my boot disk/partition. thanks. .mrg.
Re: CVS commit: src/sys/arch
Le 18/08/2017 à 20:52, matthew green a écrit : "Maxime Villard" writes: Module Name:src Committed By: maxv Date: Fri Aug 18 10:28:53 UTC 2017 Modified Files: src/sys/arch/amd64/conf: kern.ldscript src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB Log Message: Fill the .text padding with 0xcc (int3), in such a way that any jump into this area will automatically fault. The alignment within the section is necessary, in order to fill strictly all of the padding (took me a while to figure this out); but it does not change the kernel size. Greatly inspired from FreeBSD, but for some reason they decided not to apply the alignment. it's really a pity that we have almost _2MB_ of basically wasted space in the kernel. there's really no good reason for it. it's not as if ELF files are incapable of expressing discontiguous sections separately without zero or other filling. the int3 filling could be done at run time. you didn't introduce this issue, but you did add 1MB of wastage a while back now. can you please look at fixing this? I already know how to fix it, change max-page-size to 0x1000. But it causes the kernel to have three PT_LOAD sections, and the bootloader expects only two. Fixing the bootloader is more complicated, because several things are shared between architectures. it both slows boot and fills my boot disk/partition. (filling in the padding at run time is slower than having it done in the kernel statically.) Maxime
Re: CVS commit: src/sys/arch/amd64/conf
try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run. Its non-compatibility is probably buried deep within a switch statement for a generic function. The only way we can reasonably make it work is: - lie about what compat is, and build it inot the kernel, which also hurts people who want to remove it because they are using weak archs - make networking modular? - kernel hot patching (runtime cost) We can drop the pretense. it doesn't work.
Re: CVS commit: src/sys/arch/amd64/conf
See PR kern/51597 There is some rtsock stuff that does not get included in the compat module. On Sat, 19 Aug 2017, co...@sdf.org wrote: try to run 7.1 ifconfig on 8.0. without COMPAT_70 in the kernel, it won't run. Its non-compatibility is probably buried deep within a switch statement for a generic function. The only way we can reasonably make it work is: - lie about what compat is, and build it inot the kernel, which also hurts people who want to remove it because they are using weak archs - make networking modular? - kernel hot patching (runtime cost) We can drop the pretense. it doesn't work. !DSPAM:59979908113027780614962! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/arch
On Fri, Aug 18, 2017 at 10:02:37AM +, Maxime Villard wrote: > Remove unused and broken code. On amd64 we won't want int3 from kernel > mode to be valid. > - /* > - * DTrace Function Boundary Trace (fbt) probes are triggered > - * by int3 (0xcc). > - */ Is there some other trap instruction that could be used? the removal of dtrace functions breaks the ability to load the dtrace module.
Re: CVS commit: src/sys/arch
Le 18/08/2017 à 13:19, co...@sdf.org a écrit : On Fri, Aug 18, 2017 at 10:02:37AM +, Maxime Villard wrote: Remove unused and broken code. On amd64 we won't want int3 from kernel mode to be valid. - /* -* DTrace Function Boundary Trace (fbt) probes are triggered -* by int3 (0xcc). -*/ Is there some other trap instruction that could be used? the removal of dtrace functions breaks the ability to load the dtrace module. I've reverted my change. The symbols are used by the kernel module in src/external/, and I didn't check carefully enough. I had thought that the callbacks were generic C functions, and they obviously wouldn't have worked. While it seems to be not totally broken as is, it really is a bad design to have the trap frame constructed in a kernel module hidden in src/external. By the way, I don't see where segment registers are saved on i386. And at a time, we could have come from userland via vm86 and it wasn't checked. And in amd64 we don't check for userland at all. Etc. Maxime
Re: CVS commit: src/sys/arch
Le 18/08/2017 à 14:08, Maxime Villard a écrit : Le 18/08/2017 à 13:19, co...@sdf.org a écrit : On Fri, Aug 18, 2017 at 10:02:37AM +, Maxime Villard wrote: Remove unused and broken code. On amd64 we won't want int3 from kernel mode to be valid. - /* -* DTrace Function Boundary Trace (fbt) probes are triggered -* by int3 (0xcc). -*/ Is there some other trap instruction that could be used? the removal of dtrace functions breaks the ability to load the dtrace module. these branches were not used, and not implemented properly; there is no impact mmh yes, apparently there's a problem
Re: CVS commit: src/sys/arch
Le 18/08/2017 à 13:19, co...@sdf.org a écrit : On Fri, Aug 18, 2017 at 10:02:37AM +, Maxime Villard wrote: Remove unused and broken code. On amd64 we won't want int3 from kernel mode to be valid. - /* -* DTrace Function Boundary Trace (fbt) probes are triggered -* by int3 (0xcc). -*/ Is there some other trap instruction that could be used? the removal of dtrace functions breaks the ability to load the dtrace module. these branches were not used, and not implemented properly; there is no impact
Re: CVS commit: src/sys/arch
On 18.08.2017 12:02, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Fri Aug 18 10:02:37 UTC 2017 > > Modified Files: > src/sys/arch/amd64/amd64: amd64_trap.S > src/sys/arch/i386/i386: i386_trap.S vector.S > > Log Message: > Remove unused and broken code. On amd64 we won't want int3 from kernel > mode to be valid. > Does it affect DTrace? ddb(4) used to have an option to set breakpoints. signature.asc Description: OpenPGP digital signature
