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 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 <20140128141231.ga3...@britannica.bec.de>, Joerg Sonnenberger 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 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 <20140128065536.gg1...@apb-laptoy.apb.alt.za>, 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? 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 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.
