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 (with `-ffreestanding'). The GCC specific parts are now being discussed at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838. Roland, what about the glibc parts? Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[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 ___ Follow-up Comment #1: Discussion continued in the following threads http://lists.gnu.org/archive/html/bug-hurd/2006-09/msg00045.html, http://lists.gnu.org/archive/html/bug-hurd/2006-10/msg00020.html and this has eventually been fixed on glibc's trunk. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17808 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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 Add forward declarations for:
* db_exec_cmd_nest()
* ddb/db_cond.c Include: db_cond.h, db_expr.h, and db_output.h
* db_cond_cmd(): specify int for variable c
* ddb/db_cond.h New file
* ddb/db_examine.c Include: machine/db_interface.h,
ddb/db_examine.h, ddb/db_expr.h
* Remove forward declarations for: db_strcpy() and db_examine()
* db_xcdump() specify int for variables i,n
* ddb/db_examine.h New file
* ddb/db_expr.c Include: db_expr.h, db_output.h, db_sym.h, db_variables.h
* ddb/db_input.c Include: db_command.h
* ddb/db_input.h New file
* ddb/db_lex.c Include: db_command.h, db_examine.h, db_input.h,
db_output.h
* db_skip_to_eol() specify int for variables skip, t, n
* db_lex() specify int for variable c
* ddb/db_lex.h Remove forward declaration for db_lex().
* ddb/db_macro.c Include: db_examine.h, db_expr.h, db_output.h
* db_def_macro_cmd() specify int for variables c, n
* ddb/db_macro.h New file
* ddb/db_output.c Include: db_command.h
* ddb/db_output.h Add forward declaration for db_printf()
* ddb/db_print.c Include machine/db_interface.h, ddb/db_command.h,
ddb/db_output.h
* db_show_regs() specify int for variable i
* ddb/db_run.c Include: db_command.h, db_examine.h, db_output.h,
db_watch.h
* ddb/db_run.h Include kern/task.h, machine/db_machdep.h
* Add forward declarations:
* db_single_step()
* db_single_step_cmd()
* db_in_single_step()
* ddb/db_sym.c Include: db_command.h, db_output.h
* db_sym_parse_and_lookup() specify int for variable n
* ddb/db_sym.h Add forward declaration for db_line_at_pc()
* ddb/db_task_thread.c Include: db_command.h, db_expr.h, db_lex.h,
db_output.h
* db_lookup_task() specify int for variables task_id, npset
* db_lookup_task_thread() specify int for variable thread_id
* db_lookup_thread() specify int for variables thread_id, ntask, npset
* db_lookup_task_id() specify int for variables task_id, npset
* db_lookup_thread_id() specify int for variable thread_id
* ddb/db_trap.c Include: db_examine.h, db_output.h
* ddb/db_trap.h New file
* ddb/db_variables.c Include: db_command.h, db_examine.h, db_expr.h,
db_output.h
* db_get_suffix() specify int for variable value
* db_cmp_variable_name() specify int for variable level
* ddb/db_variables.h Add forward declaration for db_get_variable()
* ddb/db_watch.c db_command.h, db_expr.h, db_output.h, db_run.h
* ddb/db_write_cmd.c Include: db_expr.h, db_output.h
* i386/i386/db_interface.c Include: kern/printf.h, ddb/db_access.h,
ddb/db_command.h, ddb/db_output.h, ddb/db_run.h, ddb/db_trap.h
* kdbprinttrap() Add void return type to function declaration
* db_user_to_kernel_address() specify int for variable *kaddr
* db_task_name() specify int for variable n
* i386/i386/db_interface.h New file
* i386/i386/db_trace.c Add int return type to function declaration
for db_i386_reg_value()
* i386/i386/trap.c Include: ddb/db_watch.h, ddb/db_run.h
* ipc/ipc_kmsg.c Include: ddb/db_output.h if MACH_KDB is defined
* kern/lock.c Include: ddb/db_output.h
Thanks!
Barry deFreese (aka bddebian)
Index: ddb/db_aout.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_aout.c,v
retrieving revision 1.2.2.2
diff -u -p -r1.2.2.2 db_aout.c
--- ddb/db_aout.c 8 Nov 2006 01:45:43 - 1.2.2.2
+++ ddb/db_aout.c 15 Nov 2006 17:15:51 -
@@ -37,6 +37,7 @@
#include string.h
#include mach/std_types.h
#include machine/db_machdep.h/* data types */
+#include ddb/db_output.h
#include ddb/db_sym.h
#ifndefDB_NO_AOUT
Index: ddb/db_break.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_break.c,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 db_break.c
--- ddb/db_break.c 15 Oct 2006 14:59:03 - 1.2.2.1
+++ ddb/db_break.c 15 Nov 2006 17:15:51 -
@@ -43,6 +43,9 @@
#include ddb/db_variables.h
#include ddb/db_command.h
#include ddb/db_task_thread.h
+#include ddb/db_output.h
+#include ddb/db_cond.h
+#include ddb/db_expr.h
#defineNBREAKPOINTS100
#define NTHREAD_LIST (NBREAKPOINTS*3)
@@ -594,7 +597,7 @@ db_list_breakpoints()
void
db_delete_cmd()
{
- register n;
+ register int n;
thread_t thread;
vm_offset_t task_thd;
boolean_t user_global = FALSE;
@@ -677,7 +680,7 @@ db_breakpoint_cmd(addr, have_addr, count
db_expr_t count;
char * modif;
{
- register n;
+ register int n;
thread_t thread;
boolean_t
Maintaining the tool chain
Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', http://savannah.gnu.org/people/?group=hurd: #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 environment where the tool chain is being advanced for the Linux kernel, as an example, and subsequently the Hurd-specific parts would need to be adopted to these advancements. Please contact us mailing to bug-hurd@gnu.org if you are interested in helping here. #v- Thanks to Michael Banck for the suggestion to add such a inquiry. Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Maintaining the tool chain
Thomas Schwinge wrote: Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', http://savannah.gnu.org/people/?group=hurd: #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 environment where the tool chain is being advanced for the Linux kernel, as an example, and subsequently the Hurd-specific parts would need to be adopted to these advancements. Please contact us mailing to bug-hurd@gnu.org if you are interested in helping here. #v- Thanks to Michael Banck for the suggestion to add such a inquiry. Regards, Thomas Thomas, You know I'm game if there is anything my limited skillset can bring to the table. Thanks, Barry deFreese (aka bddebian) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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'', http://savannah.gnu.org/people/?group=hurd: #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 environment where the tool chain is being advanced for the Linux kernel, as an example, and subsequently the Hurd-specific parts would need to be adopted to these advancements. Please contact us mailing to bug-hurd@gnu.org if you are interested in helping here. #v- Thanks to Michael Banck for the suggestion to add such a inquiry. Regards, Thomas Thomas, You know I'm game if there is anything my limited skillset can bring to the table. Thanks, Barry deFreese (aka bddebian) counter++ Developing driver glue code proved too much for this rookie :) (although i learned a few things in the process). My few months of experience with the Hurd is at your service. Regards, Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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 -r1.5.2.6 trap.c --- i386/i386/trap.c 11 Nov 2006 00:54:05 - 1.5.2.6 +++ i386/i386/trap.c 15 Nov 2006 17:15:58 - @@ -60,6 +60,8 @@ extern void thread_exception_return(); extern void i386_exception(); #if MACH_KDB +#include ddb/db_watch.h +#include ddb/db_run.h boolean_tdebug_all_traps_with_kdb = FALSE; extern struct db_watchpoint *db_watchpoint_list; extern boolean_t db_watchpoints_inserted; The #includes should go at the front, with the rest of the includes. Preserve the normal order: #include ... #include ... other decls ... functions except when there is a good reason to deviate, which there does not seem to be in this case. Thomas signature.asc Description: This is a digitally signed message part ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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 retrieving revision 1.5.2.6 diff -u -p -r1.5.2.6 trap.c --- i386/i386/trap.c11 Nov 2006 00:54:05 - 1.5.2.6 +++ i386/i386/trap.c15 Nov 2006 17:15:58 - @@ -60,6 +60,8 @@ extern void thread_exception_return(); extern void i386_exception(); #if MACH_KDB +#include ddb/db_watch.h +#include ddb/db_run.h boolean_t debug_all_traps_with_kdb = FALSE; extern struct db_watchpoint *db_watchpoint_list; extern boolean_t db_watchpoints_inserted; The #includes should go at the front, with the rest of the includes. Preserve the normal order: #include ... #include ... other decls ... functions except when there is a good reason to deviate, which there does not seem to be in this case. Thomas 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. Thanks, Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[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: http://savannah.gnu.org/bugs/?17346 ___ Message posté via/par Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[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: http://savannah.gnu.org/bugs/?17346 ___ Message posté via/par Savannah http://savannah.gnu.org/ ___ 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 machine/stackinfo.h'. Does that sound right? Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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
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. But on the assumption that it is, yes, it still belongs up above. I think the very next file after this one in your patch was an example of it done right. Thomas signature.asc Description: This is a digitally signed message part ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
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-hurd
