From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31237 invoked by alias); 5 Oct 2007 07:42:34 -0000 Received: (qmail 31226 invoked by uid 22791); 5 Oct 2007 07:42:33 -0000 X-Spam-Check-By: sourceware.org Received: from ics.u-strasbg.fr (HELO ics.u-strasbg.fr) (130.79.112.250) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Oct 2007 07:42:29 +0000 Received: from ICSMULLER (laocoon.u-strasbg.fr [130.79.112.72]) by ics.u-strasbg.fr (Postfix) with ESMTP id 446EF187024 for ; Fri, 5 Oct 2007 09:47:14 +0200 (CEST) From: "Pierre Muller" To: Subject: [RFC] ARI fix: Replace sys/wait.h by gdb_wait.h in linux-fork.c Date: Fri, 05 Oct 2007 07:42:00 -0000 Message-ID: <005e01c80723$4ae0dec0$e0a29c40$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us x-cr-hashedpuzzle: AJJ5 A6uC BdWS BnwG Bx91 CHzQ CcwW DAsN DHnL ETW8 EfvE GGfS GWkG KFqb KJSb LSS8;1;ZwBkAGIALQBwAGEAdABjAGgAZQBzAEAAcwBvAHUAcgBjAGUAdwBhAHIAZQAuAG8AcgBnAA==;Sosha1_v1;7;{770829FC-61A9-461E-8B0E-91E610506758};bQB1AGwAbABlAHIAQABpAGMAcwAuAHUALQBzAHQAcgBhAHMAYgBnAC4AZgByAA==;Fri, 05 Oct 2007 07:42:29 GMT;WwBSAEYAQwBdACAAQQBSAEkAIABmAGkAeAA6ACAAUgBlAHAAbABhAGMAZQAgAHMAeQBzAC8AdwBhAGkAdAAuAGgAIABiAHkAIABnAGQAYgBfAHcAYQBpAHQALgBoACAAaQBuACAAbABpAG4AdQB4AC0AZgBvAHIAawAuAGMA x-cr-puzzleid: {770829FC-61A9-461E-8B0E-91E610506758} Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00044.txt.bz2 - This is a RFC and not a RFA for several reasons: 1) I have no access to a linux machine, and even building a gdb with linux target does not include that source. So someone should test and tell me if the patch is without regressions. 2) Are there rules about the order in which the different headers are listed? You need to remember that I am mainly a pascal programmer. In pascal language, exchanging the order in the USES clause, can leads to the fact that another function is used in the source if the same function is declared in the two included units. As this is not allowed in C, I suppose that this is not relevant, but with all that macros that get defined when parsing the headers, I am still not sure it is really safe to put the headers in a random order. I did put the gdb_wait.h together with other local headers, which seems to be a common practice in GDB sources. Is this part of coding style, or something more profound? 3) I also updated the dependency of linux-fork.o in Makefile.in, but stumbled on the same problem: is there some preferred ordering of the dependency list? I did not see something obvious ... Does it follow the declaration order in the source? Pierre Muller, trying to reduce ARIs... ChangeLog entry: 2007-10-04 Pierre Muller * linux-fork.c: ARI fix: include "gdb_wait.h" instead of . Makefile.in (linux-fork.o): Add gdb_wait.h dependency. $ cvs diff -up linux-fork.c Makefile.in Index: linux-fork.c =================================================================== RCS file: /cvs/src/src/gdb/linux-fork.c,v retrieving revision 1.12 diff -u -p -r1.12 linux-fork.c --- linux-fork.c 23 Aug 2007 18:08:35 -0000 1.12 +++ linux-fork.c 5 Oct 2007 07:31:45 -0000 @@ -26,9 +26,9 @@ #include "gdb_string.h" #include "linux-fork.h" #include "linux-nat.h" +#include "gdb_wait.h" #include -#include #include #include #include Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.939 diff -u -p -r1.939 Makefile.in --- Makefile.in 27 Sep 2007 18:48:32 -0000 1.939 +++ Makefile.in 5 Oct 2007 07:31:46 -0000 @@ -2236,7 +2236,7 @@ linespec.o: linespec.c $(defs_h) $(symta $(objc_lang_h) $(linespec_h) $(exceptions_h) $(language_h) linux-fork.o: linux-fork.c $(defs_h) $(inferior_h) $(regcache_h) $(gdbcmd_h) \ $(infcall_h) $(gdb_assert_h) $(gdb_string_h) $(linux_fork_h) \ - $(linux_nat_h) + $(linux_nat_h) $(gdb_wait_h) linux-nat.o: linux-nat.c $(defs_h) $(inferior_h) $(target_h) $(gdb_string_h) \ $(gdb_wait_h) $(gdb_assert_h) $(linux_nat_h) $(gdbthread_h) \ $(gdbcmd_h) $(regcache_h) $(regset_h) $(inf_ptrace_h) $(auxv_h) \