Re: CVS commit: src/sys/arch/i386/include
On Sun, Jun 17, 2018 at 03:46:39PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sun Jun 17 15:46:39 UTC 2018 > > Modified Files: > src/sys/arch/i386/include: frameasm.h > > Log Message: > i586 and below don't have this 3-byte nop, so use three 1-byte nops, > reported by Nathanial Sloss Can't we use 0x66 0x89 0xc0 for this purpose, i.e. movw %ax, %ax? Joerg
re: CVS commit: src/sys/arch/i386/include
In article 20140128065536.gg1...@apb-laptoy.apb.alt.za, Alan Barrett a...@cequrux.com wrote: On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? The data size limits on i386 are already annoyingly small, and I would prefer not to make them smaller. Please could you find a way to penalise only a.out programs. I don't think it could allocate 3G before either. I think that the data segment would smash into the stack then. I can test though to verify. it probably doesn't matter since most of the memory you'll end up using for a large process with be counted against RLIMIT_AS not RLIMIT_DATA, with modern malloc(3). .mrg.
Re: CVS commit: src/sys/arch/i386/include
In article 20140128065536.gg1...@apb-laptoy.apb.alt.za, Alan Barrett a...@cequrux.com wrote: On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? The data size limits on i386 are already annoyingly small, and I would prefer not to make them smaller. Please could you find a way to penalise only a.out programs. I don't think it could allocate 3G before either. I think that the data segment would smash into the stack then. I can test though to verify. christos
Re: CVS commit: src/sys/arch/i386/include
On Tue, Jan 28, 2014 at 08:55:37AM +0200, Alan Barrett wrote: On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? Which malloc? jemalloc uses mmap and doesn't count against MAXDSIZE. Joerg
Re: CVS commit: src/sys/arch/i386/include
In article 20140128141231.ga3...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Jan 28, 2014 at 08:55:37AM +0200, Alan Barrett wrote: On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? Which malloc? jemalloc uses mmap and doesn't count against MAXDSIZE. Bottomup allocations count against maxdsize, topdown don't. Nevertheless, I restored the limit back to where it was. christos
Re: CVS commit: src/sys/arch/i386/include
On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? The data size limits on i386 are already annoyingly small, and I would prefer not to make them smaller. Please could you find a way to penalise only a.out programs. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/i386/include
On Dec,Tuesday 14 2010, at 4:50 PM, Adam Hamsik wrote: Module Name: src Committed By: haad Date: Tue Dec 14 15:50:07 UTC 2010 Modified Files: src/sys/arch/i386/include: types.h Log Message: Revert change made in revision 1.66 by ad@ this is not true and 64bit atomic ops should be enabled in libc by default. This was Oked by a...@. Regards Adam.
