Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message 4f91c8fe.4070...@freebsd.org, Dimitry Andric writes: This is a multi-part message in MIME format. --030506060901050002030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so lving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. I'm now using the attached. It seems to work... It didn't work for me. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/12 13:21, Cy Schubert wrote: In message 4f91c8fe.4070...@freebsd.org, Dimitry Andric writes: This is a multi-part message in MIME format. --030506060901050002030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so lving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. I'm now using the attached. It seems to work... It didn't work for me. The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+S8CAACgkQQv9rrgRC1JJs/ACcC9Sg1n37dQICmkRkeF3dLSi/ EX8An1IjGbLT6N9YM9p6fOyGL4V6ep1f =NooP -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message 4f92f020.1000...@protected-networks.net, Michael Butler writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/12 13:21, Cy Schubert wrote: In message 4f91c8fe.4070...@freebsd.org, Dimitry Andric writes: This is a multi-part message in MIME format. --030506060901050002030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obviou s names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just thi s reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so lving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll tr y to add full coverage. I'm now using the attached. It seems to work... It didn't work for me. The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, I did. I restored from backup made a month ago and rebuilt world again. That worked. I then rebuilt world again. That's when it failed. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 2012-04-21 19:52, Cy Schubert wrote: In message4f92f020.1000...@protected-networks.net, Michael Butler writes: ... The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, I did. I restored from backup made a month ago and rebuilt world again. That worked. I then rebuilt world again. That's when it failed. At which revision was your source tree? In r234543, Jason committed the real fix, and I think that should work correctly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
/usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
I update my local mirror of the SVN repo nightly, then use it to track stable/8, stable/9, and head in the mornings -- both on my laptop on my local build machine. While that usually just works, head has been a bit more turbulent in the last few days. My last successful build of head is reflected in: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #537 234416M: Wed Apr 18 05:35:03 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 (I note that I have not attempted to migrate to using clang/llvm to perform the build.) The update after 234416 was to 234454; the attempted buildworld failed: -- Building an up-to-date make(1) -- cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\520300\ -DDEFSHELLNAME=\sh\ -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\520300\ -DDEFSHELLNAME=\sh\ -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/buf.c ... === tools/build (obj,includes,depend,all,install) cd /usr/src/tools/build; /usr/obj/usr/src/make.i386/make buildincludes; /usr/obj/usr/src/make.i386/make installincludes sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib -- stage 1.2: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION=FreeBSD 10.0-CURRENT i386 111 MAKEFLAGS=-m /usr/src/tools/build/mk -j 4 -D NOCLEAN -m /usr/src/share/mk TARGET=i386 TARGET_ARCH=i386 /usr/obj/usr/src/make.i386/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=111 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF bootstrap-tools === lib/clang/libllvmsupport (obj,depend,all,install) ... c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenBackend.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I.
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
yep, I sent PR for this issue;) http://www.freebsd.org/cgi/query-pr.cgi?pr=167064 On Fri, 20 Apr 2012 05:57:18 -0700 David Wolfskill da...@catwhisker.org wrote: I update my local mirror of the SVN repo nightly, then use it to track stable/8, stable/9, and head in the mornings -- both on my laptop on my local build machine. While that usually just works, head has been a bit more turbulent in the last few days. My last successful build of head is reflected in: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #537 234416M: Wed Apr 18 05:35:03 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 (I note that I have not attempted to migrate to using clang/llvm to perform the build.) The update after 234416 was to 234454; the attempted buildworld failed: -- Building an up-to-date make(1) -- cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\520300\ -DDEFSHELLNAME=\sh\ -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\520300\ -DDEFSHELLNAME=\sh\ -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/buf.c ... === tools/build (obj,includes,depend,all,install) cd /usr/src/tools/build; /usr/obj/usr/src/make.i386/make buildincludes; /usr/obj/usr/src/make.i386/make installincludes sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib -- stage 1.2: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION=FreeBSD 10.0-CURRENT i386 111 MAKEFLAGS=-m /usr/src/tools/build/mk -j 4 -D NOCLEAN -m /usr/src/share/mk TARGET=i386 TARGET_ARCH=i386 /usr/obj/usr/src/make.i386/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=111 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF bootstrap-tools === lib/clang/libllvmsupport (obj,depend,all,install) ... c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenBackend.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I. -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cpp c++ -O2 -pipe
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 2012-04-20 15:55, Michael Pounov wrote: On Fri, 20 Apr 2012 05:57:18 -0700 David Wolfskillda...@catwhisker.org wrote: ... The update after 234416 was to 234454; the attempted buildworld failed: ... /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes yep, I sent PR for this issue;) http://www.freebsd.org/cgi/query-pr.cgi?pr=167064 The root cause of this is the new jemalloc import in r234370. In contrib/jemalloc/src/chunk.c, this defines a global variable called 'chunksize'. At run-time, this turns out to have a value of 4194304, at least on my i386 system. However, GNU as *also* has a global variable called 'chunksize', with a very different intent: it is the default chunk size for its so-called obstacks, an internal implementation detail. It is set to zero in contrib/binutils/gas/as.c, but normally ends up as 4096 during further initialization. Now, because the variable from jemalloc ends up in libc.a, and /usr/bin/as is statically linked, the jemalloc variable overrides the one from GNU as. This causes as to allocate 4 MiB chunks instead of 4 KiB chunks for all its internal processing, and you can guess what happens with a reasonably large input file. :) I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: On 2012-04-20 15:55, Michael Pounov wrote: On Fri, 20 Apr 2012 05:57:18 -0700 David Wolfskillda...@catwhisker.org wrote: ... The update after 234416 was to 234454; the attempted buildworld failed: ... /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes yep, I sent PR for this issue;) http://www.freebsd.org/cgi/query-pr.cgi?pr=167064 The root cause of this is the new jemalloc import in r234370. In contrib/jemalloc/src/chunk.c, this defines a global variable called 'chunksize'. At run-time, this turns out to have a value of 4194304, at least on my i386 system. However, GNU as *also* has a global variable called 'chunksize', with a very different intent: it is the default chunk size for its so-called obstacks, an internal implementation detail. It is set to zero in contrib/binutils/gas/as.c, but normally ends up as 4096 during further initialization. Now, because the variable from jemalloc ends up in libc.a, and /usr/bin/as is statically linked, the jemalloc variable overrides the one from GNU as. This causes as to allocate 4 MiB chunks instead of 4 KiB chunks for all its internal processing, and you can guess what happens with a reasonably large input file. :) I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Thanks, Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: ... I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: ... I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 04/20/2012 01:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: ... I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. Prefixing your variables sounds right to me ... I'd use jem_ instead of spelling out jemalloc_, but either should work. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. I'm now using the attached. It seems to work... Index: contrib/jemalloc/include/jemalloc/internal/private_namespace.h === --- contrib/jemalloc/include/jemalloc/internal/private_namespace.h (revision 234443) +++ contrib/jemalloc/include/jemalloc/internal/private_namespace.h (working copy) @@ -1,5 +1,6 @@ #define arena_alloc_junk_small JEMALLOC_N(arena_alloc_junk_small) #define arena_bin_index JEMALLOC_N(arena_bin_index) +#define arena_bin_info JEMALLOC_N(arena_bin_info) #define arena_boot JEMALLOC_N(arena_boot) #define arena_dalloc JEMALLOC_N(arena_dalloc) #define arena_dalloc_bin JEMALLOC_N(arena_dalloc_bin) @@ -8,6 +9,7 @@ #define arena_malloc JEMALLOC_N(arena_malloc) #define arena_malloc_large JEMALLOC_N(arena_malloc_large) #define arena_malloc_small JEMALLOC_N(arena_malloc_small) +#define arena_maxclass JEMALLOC_N(arena_maxclass) #define arena_new JEMALLOC_N(arena_new) #define arena_palloc JEMALLOC_N(arena_palloc) #define arena_postfork_child JEMALLOC_N(arena_postfork_child) @@ -24,9 +26,11 @@ #define arena_salloc JEMALLOC_N(arena_salloc) #define arena_stats_merge JEMALLOC_N(arena_stats_merge) #define arena_tcache_fill_small JEMALLOC_N(arena_tcache_fill_small) +#define arenas JEMALLOC_N(arenas) #define arenas_bin_i_index JEMALLOC_N(arenas_bin_i_index) #define arenas_cleanup JEMALLOC_N(arenas_cleanup) #define arenas_extend JEMALLOC_N(arenas_extend) +#define arenas_lock JEMALLOC_N(arenas_lock) #define arenas_lrun_i_index JEMALLOC_N(arenas_lrun_i_index) #define arenas_tls JEMALLOC_N(arenas_tls) #define arenas_tsd_boot JEMALLOC_N(arenas_tsd_boot) @@ -75,6 +79,11 @@ #define chunk_dss_prefork JEMALLOC_N(chunk_dss_prefork) #define chunk_in_dss JEMALLOC_N(chunk_in_dss) #define chunk_mmap_boot JEMALLOC_N(chunk_mmap_boot) +#define chunk_npages JEMALLOC_N(chunk_npages) +#define chunks_mtx JEMALLOC_N(chunks_mtx) +#define chunks_rtree JEMALLOC_N(chunks_rtree) +#define chunksize JEMALLOC_N(chunksize) +#define chunksize_mask JEMALLOC_N(chunksize_mask) #define ckh_bucket_search JEMALLOC_N(ckh_bucket_search) #define ckh_count JEMALLOC_N(ckh_count) #define ckh_delete JEMALLOC_N(ckh_delete) @@ -129,9 +138,13 @@ #define extent_tree_szad_reverse_iter_start JEMALLOC_N(extent_tree_szad_reverse_iter_start) #define extent_tree_szad_search JEMALLOC_N(extent_tree_szad_search) #define hash JEMALLOC_N(hash) +#define huge_allocated JEMALLOC_N(huge_allocated) #define huge_boot JEMALLOC_N(huge_boot) #define huge_dalloc JEMALLOC_N(huge_dalloc) #define huge_malloc JEMALLOC_N(huge_malloc) +#define huge_mtx JEMALLOC_N(huge_mtx) +#define huge_ndalloc JEMALLOC_N(huge_ndalloc) +#define huge_nmalloc JEMALLOC_N(huge_nmalloc) #define huge_palloc JEMALLOC_N(huge_palloc) #define huge_postfork_child JEMALLOC_N(huge_postfork_child) #define huge_postfork_parent JEMALLOC_N(huge_postfork_parent) @@ -153,6 +166,7 @@ #define jemalloc_postfork_child JEMALLOC_N(jemalloc_postfork_child) #define jemalloc_postfork_parent JEMALLOC_N(jemalloc_postfork_parent) #define jemalloc_prefork JEMALLOC_N(jemalloc_prefork) +#define malloc_conf JEMALLOC_N(malloc_conf) #define malloc_cprintf JEMALLOC_N(malloc_cprintf) #define malloc_mutex_init JEMALLOC_N(malloc_mutex_init) #define malloc_mutex_lock JEMALLOC_N(malloc_mutex_lock) @@ -171,12 +185,16 @@ #define malloc_vcprintf JEMALLOC_N(malloc_vcprintf) #define malloc_vsnprintf JEMALLOC_N(malloc_vsnprintf) #define malloc_write JEMALLOC_N(malloc_write) +#define map_bias JEMALLOC_N(map_bias) #define mb_write JEMALLOC_N(mb_write) #define mmap_unaligned_tsd_boot JEMALLOC_N(mmap_unaligned_tsd_boot) #define mmap_unaligned_tsd_cleanup_wrapper JEMALLOC_N(mmap_unaligned_tsd_cleanup_wrapper) #define mmap_unaligned_tsd_get JEMALLOC_N(mmap_unaligned_tsd_get) #define mmap_unaligned_tsd_set JEMALLOC_N(mmap_unaligned_tsd_set) #define mutex_boot JEMALLOC_N(mutex_boot) +#define narenas JEMALLOC_N(narenas)
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 4/20/12 1:37 PM, Dimitry Andric wrote: On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? We do that with our driver.. variables and functions.. the symbols are all mangled in the .o file. Ah right, functions only. Well then, I don't have any bright ideas for solving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. I'm now using the attached. It seems to work... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
