Re: Direction of the stack's growth

Roland McGrath, le Wed 15 Nov 2006 17:33:51 -0800, a écrit : > What in machine-independent kernel source code needs such a macro? Stack smashing detection. Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hur

Re: Gnumach cleanup Round 6

On Wed, 2006-11-15 at 15:55 -0500, Barry deFreese wrote: > > > Thomas, > > Thanks for the reply. Are you saying I should wrap those includes > around an #ifdef MACH_KDB up where the other includes are? If so, that > makes sense to me. I did not check whether the MACH_KDB check is right. B

Re: Direction of the stack's growth

What in machine-independent kernel source code needs such a macro? ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Direction of the stack's growth

Hello! In GNU Mach we currently don't have a macro to indicate the direction into which the stack grows. I thought about installing glibc's `sysdeps/i386/stackinfo.h' into `[GNU Mach]/i386/i386/stackinfo.h' and then use `#include '. Does that sound right? Regards, Thomas signature.asc Descr

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

Update of bug #17346 (project hurd): Status: Fixed => None Open/Closed: Closed => Open ___ Reply to this item at:

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

Update of bug #17346 (project hurd): Status:None => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

Re: Gnumach cleanup Round 6

Thomas Bushnell BSG wrote: On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote: Hi folks, it's your favorite PITA again.. :-) Index: i386/i386/trap.c === RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v retrievin

Re: Gnumach cleanup Round 6

On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote: > Hi folks, it's your favorite PITA again.. :-) > Index: i386/i386/trap.c > === > RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v > retrieving revision 1.5.2.6 > diff -u -p -

Re: Maintaining the tool chain

Barry deFreese wrote: Thomas Schwinge wrote: Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', : #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mos

Re: Maintaining the tool chain

Thomas Schwinge wrote: Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', : #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mostly GCC, binutils and g

Maintaining the tool chain

Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', : #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mostly GCC, binutils and glibc) up-to-date in an envi

Gnumach cleanup Round 6

Hi folks, it's your favorite PITA again.. :-) * ddb/db_aout.c Include: db_output.h * ddb/db_break.c Include: db_cond.h, db_output.h, and db_expr.h * db_delete_cmd(): specify int for variable n * ddb/db_command.c Include: db_macro.h, db_expr.h, and db_examine.h * ddb/db_command.h Ad

[bug #17808] NULL timeval does not return current date/time in futimes.c

Update of bug #17808 (project hurd): Status:None => Fixed Assigned to:None => roland Open/Closed:Open => Closed

Re: %gs:0x14

Hello! On Tue, Nov 14, 2006 at 04:15:08PM +0100, Thomas Schwinge wrote: > Using `-fstack-protector' with GCC 4.1 made it include assembler code > using ``%gs:0x14'' even with `-ffreestanding'. However, this isn't the > correct thing to do on a) GNU/Hurd user space and neither b) in kernel > space