Re: [bug #18217] glibc: `__libc_once'

Uli abused the macros. To support the use he wants, __libc_once should be revamped in all its implementations to return a value or have a variant that does (value says whether fn just ran). ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.or

Re: [bug #18218] glibc: `MSG_NOSIGNAL'

best would be to implement MSG_NOSIGNAL in sendmsg. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: %gs:0x14

I think it really ought to be controlled by a -mno-stack-protector-tls or suchlike, for complete flexibility. Obviously it should default to disabled for -ffreestanding. Those are GCC quality issues. AFAIK, it does configure checks on the installed libc for linux configs to decide the ssp stuff.

[bug #17120] GNU Mach debian dir

Follow-up Comment #3, bug #17120 (project hurd): Isn't it standard practice not to include debian dirs in upstream tarballs? What's the issue with just removing this? Thanks. ___ Reply to this item at:

Re: [bug #17346] GNU mach can't handle 4GB memory

On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote: > All the above solutions aim to make Mach unaware of any memory > above 1 GB. Isn't it possible to utilise all the memory? I will > explain myself. I think this is clearly right, but it may well require more substantial changes to

Re: [bug #17647] glibc: GCC 4.1

Thomas Schwinge, le Sun 19 Nov 2006 22:33:46 +, a écrit : > printf ("%s:fa[0] = %u\tfa[1] = %u\tra = %u\n", __func__, fa[0], fa[1], > $ gcc-4.0 test.c && ./a.out > main:fa = 3216472808fa[1] = 3084724428 ra = 3084724428 > func:fa[0] = 3216472808 fa[1] = 134513645 ra = 134513645

[task #6111] Release GNU Mach 1.4

Update of task #6111 (project hurd): Dependency Removed: => task #5782 ___ Reply to this item at: ___ Messag

Re: [bug #17346] GNU mach can't handle 4GB memory

Constantine Kousoulos, le Mon 20 Nov 2006 16:27:07 +0200, a écrit : > Oops wrong copy-paste. Correct my previous email with this: > > ... Mach's virtual address space is 4 GB big according to this > entry in gnumach/i386/i386/vm_param.h: #define > LINEAR_MAX_KERNEL_ADDRESS ((vm_offset_t) 0xf

Re: Building the GNU/Hurd glibc with GCC 4.1, problem with `__builtin_frame_address'

On Mon, Nov 20, 2006 at 11:50:44AM +0100, Thomas Schwinge wrote: > There is a problem when building glibc for GNU/Hurd with GCC 4.1, see > . This is due to a change in the > behavior of `__builtin_frame_address' in GCC 4.1: The example you give is a test that

Re: [bug #17647] glibc: GCC 4.1

Thomas Schwinge, le Sun 19 Nov 2006 22:59:29 +, a écrit : > | #v+ > | [...] > | void > | -_dl_init_first (int argc, ...) > | +_dl_init_first (void) > | { > | first_init (); > | > | - init (&argc); > | + init ((int *) __builtin_frame_address (0) + 2); > | } > | [...] > | #v- > > > So, how can

Re: [bug #17346] GNU mach can't handle 4GB memory

Samuel Thibault wrote: Constantine Kousoulos, le Mon 20 Nov 2006 16:27:07 +0200, a écrit : Oops wrong copy-paste. Correct my previous email with this: ... Mach's virtual address space is 4 GB big according to this entry in gnumach/i386/i386/vm_param.h: #define LINEAR_MAX_KERNEL_ADDRESS ((vm_o

Re: [bug #17346] GNU mach can't handle 4GB memory

Hello, All the above solutions aim to make Mach unaware of any memory above 1 GB. Isn't it possible to utilise all the memory? I will explain myself. Why don't we make Mach's kernel address space larger so that the whole memory can fit inside it? Mach's virtual address space is 4 GB big acc

Re: [bug #17346] GNU mach can't handle 4GB memory

In gnumach/i386/include/mach/i386/vm_param.h: /* User address spaces are 3GB each, starting at virtual and linear address 0. */ #define VM_MIN_ADDRESS ((vm_offset_t) 0) #define VM_MAX_ADDRESS ((vm_offset_t) 0xc000) In gnumach/i386/i386/vm_param.h: /* The kernel address s

[patch #5328] GNU Mach asm statements tidy

Update of patch #5328 (project hurd): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at:

Re: [bug #17346] GNU mach can't handle 4GB memory

Thomas Bushnell BSG wrote: On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote: All the above solutions aim to make Mach unaware of any memory above 1 GB. Isn't it possible to utilise all the memory? I will explain myself. I think this is clearly right, but it may well require more

[patch #5375] Fix de4x5 probe

Update of patch #5375 (project hurd): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at:

Re: [bug #17346] GNU mach can't handle 4GB memory

On Tue, Nov 21, 2006 at 02:12:33PM +0200, Constantine Kousoulos wrote: > Thomas Bushnell BSG wrote: > >On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote: > >>All the above solutions aim to make Mach unaware of any memory > >>above 1 GB. Isn't it possible to utilise all the memory? I w