From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: cgf@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] fix child_xfer_memory in hppah-nat.c Date: Tue, 06 Feb 2001 08:37:00 -0000 Message-id: <200102061637.LAA08729@indy.delorie.com> References: <3A7DCAB6.333C1DE0@cygnus.com> <20010205131813.A734@redhat.com> X-SW-Source: 2001-02/msg00075.html > Date: Mon, 5 Feb 2001 13:18:14 -0500 > From: Christopher Faylor > > Here are the lines from configure.in: > > # NOTE: Don't add -Wall or -Wunused, they both include > # -Wunused-parameter which reports bogus warnings. > > The TODO has some words, too: > > Frequently requested but not approved requests. > > -- > > Eliminate unused argument warnings using ATTRIBUTE_UNUSED. > > The benefits on this one are thought to be marginal - GDBs design > means that unused parameters are very common. GCC 3.0 will also > include the option -Wno-unused-parameter which means that ``-Wall > -Wno-unused-parameters -Werror'' can be specified. > > > >Several files in the CVS use ATTRIBUTE_UNUSED (not surprisingly, > >go32-nat.c is one of them ;-). So I wonder what is the current say-so > >on this matter. > > I specifically added some of these to win32-nat.c, too, not too long ago. > I do remember the discussion now. I can't say that I agree with it, > but I remember it. > > It looks like at least one discussion is here: > > http://sources.redhat.com/ml/gdb/2000-q1/msg00826.html Thanks for the pointers. However, after reading those, I'm still unsure what, if anything, should I do with ATTRIBUTE_UNUSED in files I'm responsible for. The TODO snippet seems to say that ATTRIBUTE_UNUSED should be deleted, and we should endure the warnings until GCC 3.0 conquers the face of Earth. The discussion you pointed to seems to say the same, albeit differently: it tells that GCC options should be changed to avoid triggering the warnings which require ATTRIBUTE_UNUSED. I remember that I added ATTRIBUTE_UNUSED to stop those warnings from popping up and obscuring the real warnings (such as the one about the missing mem_attrib parameter in go32_xfer_memory that I fixed the other day). I also set up a special set of compiler switches (in gdb/config/djgpp/djconfig.sh) to make sure these warnings don't return. But to remove ATTRIBUTE_UNUSED from the sources we need a more safe assumption to bet on... Andrew? >From eliz@delorie.com Tue Feb 06 08:38:00 2001 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com, fpastor.etra-id@etra.es Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs. Date: Tue, 06 Feb 2001 08:38:00 -0000 Message-id: <200102061638.LAA08744@indy.delorie.com> References: <3A7F6BCF.605B1D7F@cygnus.com> X-SW-Source: 2001-02/msg00076.html Content-length: 1082 > Date: Mon, 05 Feb 2001 19:13:19 -0800 > From: Andrew Cagney > > Eli Zaretskii wrote: > > > > FYI: I committed today the following patch: > > > > 2001-02-04 Eli Zaretskii > > > > * ser-go32.c (dos_write) [UART_FIFO_WORKS]: Use outportsb only if > > UART_FIFO_WORKS is defined. Otherwise use outportb. > > From Francisco Pastor > > Eli, would it be better to make this a run-time option? You mean, introduce a new interactive command, or an option for an existing command? If you think this would be a good idea, I'll put that on my todo (I have a few much more important issues to deal with, such as the unified handling of hardware-assisted watchpoints and breakpoints for x86, which I promised a long time ago, as well as a few bugs). It didn't seem to me as a grave problem to make this a compile-time option because I don't think the speed we gain by using OUTS vs OUT is significant. (I also cannot test this code on my machine, since I don't have a serial link set up.) >From ac131313@cygnus.com Tue Feb 06 11:06:00 2001 From: Andrew Cagney To: Eli Zaretskii Cc: cgf@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] fix child_xfer_memory in hppah-nat.c Date: Tue, 06 Feb 2001 11:06:00 -0000 Message-id: <3A804A32.D816139E@cygnus.com> References: <3A7DCAB6.333C1DE0@cygnus.com> <20010205131813.A734@redhat.com> <200102061637.LAA08729@indy.delorie.com> X-SW-Source: 2001-02/msg00077.html Content-length: 1603 Eli Zaretskii wrote: > > > Date: Mon, 5 Feb 2001 13:18:14 -0500 > > From: Christopher Faylor > > > > Here are the lines from configure.in: > > > > # NOTE: Don't add -Wall or -Wunused, they both include > > # -Wunused-parameter which reports bogus warnings. > > > > The TODO has some words, too: > > > > Frequently requested but not approved requests. > > > > -- > > > > Eliminate unused argument warnings using ATTRIBUTE_UNUSED. > > > > The benefits on this one are thought to be marginal - GDBs design > > means that unused parameters are very common. GCC 3.0 will also > > include the option -Wno-unused-parameter which means that ``-Wall > > -Wno-unused-parameters -Werror'' can be specified. > > > > > > >Several files in the CVS use ATTRIBUTE_UNUSED (not surprisingly, > > >go32-nat.c is one of them ;-). So I wonder what is the current say-so > > >on this matter. > > > > I specifically added some of these to win32-nat.c, too, not too long ago. > > I do remember the discussion now. I can't say that I agree with it, > > but I remember it. > > > > It looks like at least one discussion is here: > > > > http://sources.redhat.com/ml/gdb/2000-q1/msg00826.html > > Thanks for the pointers. > > However, after reading those, I'm still unsure what, if anything, > should I do with ATTRIBUTE_UNUSED in files I'm responsible for. Nothing! You've plenty of other things to do above and beyond worrying about them. Just don't be suprised if someone some day submits a patch to eliminate them (like chris just did for a bunch of PTRs). Andrew >From taylor@cygnus.com Tue Feb 06 11:15:00 2001 From: David Taylor To: gdb-patches@sourceware.cygnus.com Subject: [RFA] parse_frame_specification (stack.c) Date: Tue, 06 Feb 2001 11:15:00 -0000 Message-id: <200102061915.OAA00445@texas.cygnus.com> X-SW-Source: 2001-02/msg00079.html Content-length: 2053 In gdb, if you say: "frame " or "info frame " then you expect to either move up or down some number of frames or to get information on the frame having the specified "index". But, if for your gdb target, addresses and pointers are different, then the current code in parse_frame_specification will treat the number as a pointer and convert it to an address. So, if you have a Harvard architecture processor where a pointer of 0 (say) corresponds to a text address of 0x2000000 and a data address of 0x1000000, and you say frame 0 then gdb will try to move to frame 0x1000000. Assuming you don't have that many frames, it will then try to create a frame at address 0x1000000. Which, in my case, will generate an error... This fixes it so that frame 0 will do the right thing on such configurations. ChangeLog entry: * stack.c (parse_frame_specification): For one argument case, handle the situation where the argument is an integer, not an address -- arguably the most common case. This matters on targets where pointers and addresses are different. Index: stack.c =================================================================== RCS file: /cvs/src/src/gdb/stack.c,v retrieving revision 1.11 diff -c -r1.11 stack.c *** stack.c 2001/01/27 17:57:53 1.11 --- stack.c 2001/02/06 19:01:15 *************** *** 722,727 **** --- 722,728 ---- int numargs = 0; #define MAXARGS 4 CORE_ADDR args[MAXARGS]; + int level; if (frame_exp) { *************** *** 742,747 **** --- 743,752 ---- { tmp_cleanup = make_cleanup (xfree, addr_string); + + if (numargs == 0) + level = parse_and_eval_long (addr_string); + args[numargs++] = parse_and_eval_address (addr_string); do_cleanups (tmp_cleanup); } *************** *** 762,768 **** /* NOTREACHED */ case 1: { - int level = args[0]; struct frame_info *fid = find_relative_frame (get_current_frame (), &level); struct frame_info *tfid; --- 767,772 ---- >From ac131313@cygnus.com Tue Feb 06 11:15:00 2001 From: Andrew Cagney To: Francisco Pastor Cc: Eli Zaretskii , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs. Date: Tue, 06 Feb 2001 11:15:00 -0000 Message-id: <3A804C5F.9F2B6D84@cygnus.com> References: <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> X-SW-Source: 2001-02/msg00078.html Content-length: 650 Francisco Pastor wrote: > The problem with OUTS only happen with NT DOS console, not with true DOS > 6.22. So, I think that a general solution is leave the patch with a compile > time option or, perhaps, test the DOS version for avoid the use of OUTS. I > don´t think that introduce a new interactive command be a good solution. I've been assuming that a single DJGPP-GDB binary can run on all dos platforms (6.22, NT, ...). If that is the case then the serial configury should be run-time configurable. If that isn't the case then a compile time flag is ok. I suspect this will go onto Eli's very long to do one day list :-) enjoy, Andrew >From msnyder@cygnus.com Tue Feb 06 11:17:00 2001 From: Michael Snyder To: gary37@seed.net.tw Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdbserver arm-linux support? Date: Tue, 06 Feb 2001 11:17:00 -0000 Message-id: <3A804DE9.962848E@cygnus.com> References: X-SW-Source: 2001-02/msg00080.html Content-length: 1015 gary37@seed.net.tw wrote: > > Hi all, > > I know this question has been asked before in this list > but I got gdb 20001208 source and tried to apply the > patches floating around here before. I can not successfully > apply the patches into source tree. I tried to do it > manually but found the source seems to be changed since. > So, I fumbled the code a little and finally got the > arm-linux gdbserver built ok. > > But, when I am on a x86 host run gdb and arm client runs > gdbserver, the connection seems to be up, but while I > simply want to run the debugged program at host, it told > me "don't know how to run", and the client gdbserver shows > "killing the inferior ..." and dies. When you use "target remote", you do not say "run". You say "continue". Just imagine that when you initially connect, the process already exists and the PC is stopped at the start address. Try that, anyway, and see if it works. Something like: (gdb) target remote foo (gdb) break main (gdb) continue HTH, Michael >From jtc@redback.com Tue Feb 06 11:44:00 2001 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: Francisco Pastor , Eli Zaretskii , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs. Date: Tue, 06 Feb 2001 11:44:00 -0000 Message-id: <5mitmnsik8.fsf@jtc.redback.com> References: <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> <3A804C5F.9F2B6D84@cygnus.com> X-SW-Source: 2001-02/msg00081.html Content-length: 1112 >>>>> "Andrew" == Andrew Cagney writes: Andrew> Francisco Pastor wrote: >> The problem with OUTS only happen with NT DOS console, not with true DOS >> 6.22. So, I think that a general solution is leave the patch with a compile >> time option or, perhaps, test the DOS version for avoid the use of OUTS. I >> don´t think that introduce a new interactive command be a good solution. Andrew> I've been assuming that a single DJGPP-GDB binary can run on Andrew> all dos platforms (6.22, NT, ...). If that is the case then Andrew> the serial configury should be run-time configurable. If that Andrew> isn't the case then a compile time flag is ok. Andrew> Andrew> I suspect this will go onto Eli's very long to do one day list :-) Eli mentioned that he didn't think the speed gain from using OUTS vs. OUT was significant. If that is really the case, why not use the conservative approach and always use OUT? If there isn't a win, I can't see the value of having knobs to tweak the implement- ation, either at compile time or run time. --jtc -- J.T. Conklin RedBack Networks >From eliz@delorie.com Tue Feb 06 11:50:00 2001 From: Eli Zaretskii To: ac131313@cygnus.com Cc: fpastor.etra-id@etra.es, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs. Date: Tue, 06 Feb 2001 11:50:00 -0000 Message-id: <200102061950.OAA13398@indy.delorie.com> References: <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> <3A804C5F.9F2B6D84@cygnus.com> X-SW-Source: 2001-02/msg00082.html Content-length: 766 > Date: Tue, 06 Feb 2001 11:11:27 -0800 > From: Andrew Cagney > > Francisco Pastor wrote: > > > The problem with OUTS only happen with NT DOS console, not with true DOS > > 6.22. So, I think that a general solution is leave the patch with a compile > > time option or, perhaps, test the DOS version for avoid the use of OUTS. I > > don't think that introduce a new interactive command be a good solution. > > I've been assuming that a single DJGPP-GDB binary can run on all dos > platforms (6.22, NT, ...). This is true. DJGPP programs run on MS-DOS, all versions of MS-Windows, and any other environment that has some kind of ``DOS Box'' (OS/2, DOSEmu, etc.) > I suspect this will go onto Eli's very long to do one day list :-) Yes ;-) >From msnyder@cygnus.com Tue Feb 06 12:03:00 2001 From: Michael Snyder To: gdb-patches@sources.redhat.com Cc: hilfingr@gnat.com Subject: [PATCH]: Allow compilation by Sun cc Date: Tue, 06 Feb 2001 12:03:00 -0000 Message-id: <3A8058A8.5DE5CC35@cygnus.com> X-SW-Source: 2001-02/msg00083.html Content-length: 10483 I've checked in this portion of Paul Hilfinger's patch for compiling with Sun cc. 2001-02-06 Michael Snyder Submitted by Paul Hilfinger (hilfingr@gnat.com) and Andrei Petrov (and@genesyslab.com). * findvar.c: Buffers of size MAX_REGISTER_RAW_SIZE or REGISTER_BYTES must be allocated dynamically, since these are no longer constants. * infcmd.c: Ditto. * regcache.c: Ditto. * remote.c: Ditto. * sol-thread.c: Ditto. * valops.c: Ditto. * config/sparc/sun4sol2.mh (MH_CFLAGS): Add -I/usr/include/v9, as a work-around for a missing Sun header file in solaris for sparc64. Index: gdb/findvar.c =================================================================== RCS file: /cvs/src/src/gdb/findvar.c,v retrieving revision 1.15 diff -c -3 -p -r1.15 findvar.c *** findvar.c 2000/07/30 01:48:25 1.15 --- findvar.c 2001/02/06 19:52:57 *************** value_of_register (int regnum) *** 393,399 **** CORE_ADDR addr; int optim; register value_ptr reg_val; ! char raw_buffer[MAX_REGISTER_RAW_SIZE]; enum lval_type lval; get_saved_register (raw_buffer, &optim, &addr, --- 393,399 ---- CORE_ADDR addr; int optim; register value_ptr reg_val; ! char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE); enum lval_type lval; get_saved_register (raw_buffer, &optim, &addr, *************** addresses have not been bound by the dyn *** 606,612 **** case LOC_BASEREG: case LOC_BASEREG_ARG: { ! char buf[MAX_REGISTER_RAW_SIZE]; get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), NULL); addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var))); --- 606,612 ---- case LOC_BASEREG: case LOC_BASEREG_ARG: { ! char *buf = (char*) alloca (MAX_REGISTER_RAW_SIZE); get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), NULL); addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var))); *************** addresses have not been bound by the dyn *** 616,622 **** case LOC_THREAD_LOCAL_STATIC: { ! char buf[MAX_REGISTER_RAW_SIZE]; get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), NULL); --- 616,622 ---- case LOC_THREAD_LOCAL_STATIC: { ! char *buf = (char*) alloca (MAX_REGISTER_RAW_SIZE); get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), NULL); *************** addresses have not been bound by the dyn *** 711,717 **** value_ptr value_from_register (struct type *type, int regnum, struct frame_info *frame) { ! char raw_buffer[MAX_REGISTER_RAW_SIZE]; CORE_ADDR addr; int optim; value_ptr v = allocate_value (type); --- 711,717 ---- value_ptr value_from_register (struct type *type, int regnum, struct frame_info *frame) { ! char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE); CORE_ADDR addr; int optim; value_ptr v = allocate_value (type); Index: gdb/infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.19 diff -c -3 -p -r1.19 infcmd.c *** infcmd.c 2001/01/31 01:24:01 1.19 --- infcmd.c 2001/02/06 19:52:57 *************** do_registers_info (int regnum, int fpreg *** 1467,1474 **** for (i = 0; i < numregs; i++) { ! char raw_buffer[MAX_REGISTER_RAW_SIZE]; ! char virtual_buffer[MAX_REGISTER_VIRTUAL_SIZE]; /* Decide between printing all regs, nonfloat regs, or specific reg. */ if (regnum == -1) --- 1467,1474 ---- for (i = 0; i < numregs; i++) { ! char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE); ! char *virtual_buffer = (char*) alloca (MAX_REGISTER_VIRTUAL_SIZE); /* Decide between printing all regs, nonfloat regs, or specific reg. */ if (regnum == -1) Index: gdb/regcache.c =================================================================== RCS file: /cvs/src/src/gdb/regcache.c,v retrieving revision 1.14 diff -c -3 -p -r1.14 regcache.c *** regcache.c 2001/01/09 00:12:48 1.14 --- regcache.c 2001/02/06 19:52:57 *************** write_register_bytes (int myregstart, ch *** 558,564 **** /* The register partially overlaps the range being written. */ else { ! char regbuf[MAX_REGISTER_RAW_SIZE]; /* What's the overlap between this register's bytes and those the caller wants to write? */ int overlapstart = max (regstart, myregstart); --- 558,564 ---- /* The register partially overlaps the range being written. */ else { ! char *regbuf = (char*) alloca (MAX_REGISTER_RAW_SIZE); /* What's the overlap between this register's bytes and those the caller wants to write? */ int overlapstart = max (regstart, myregstart); Index: gdb/remote.c =================================================================== RCS file: /cvs/src/src/gdb/remote.c,v retrieving revision 1.36 diff -c -3 -p -r1.36 remote.c *** remote.c 2001/02/02 19:14:33 1.36 --- remote.c 2001/02/06 19:52:58 *************** remote_wait (int pid, struct target_wait *** 2604,2610 **** { int i; long regno; ! char regs[MAX_REGISTER_RAW_SIZE]; /* Expedited reply, containing Signal, {regno, reg} repeat */ /* format is: 'Tssn...:r...;n...:r...;n...:r...;#cc', where --- 2604,2610 ---- { int i; long regno; ! char* regs = (char*) alloca (MAX_REGISTER_RAW_SIZE); /* Expedited reply, containing Signal, {regno, reg} repeat */ /* format is: 'Tssn...:r...;n...:r...;n...:r...;#cc', where *************** remote_async_wait (int pid, struct targe *** 2825,2831 **** { int i; long regno; ! char regs[MAX_REGISTER_RAW_SIZE]; /* Expedited reply, containing Signal, {regno, reg} repeat */ /* format is: 'Tssn...:r...;n...:r...;n...:r...;#cc', where --- 2825,2831 ---- { int i; long regno; ! char* regs = (char*) alloca (MAX_REGISTER_RAW_SIZE); /* Expedited reply, containing Signal, {regno, reg} repeat */ /* format is: 'Tssn...:r...;n...:r...;n...:r...;#cc', where Index: gdb/sol-thread.c =================================================================== RCS file: /cvs/src/src/gdb/sol-thread.c,v retrieving revision 1.20 diff -c -3 -p -r1.20 sol-thread.c *** sol-thread.c 2001/01/24 21:01:02 1.20 --- sol-thread.c 2001/02/06 19:52:58 *************** sol_thread_store_registers (int regno) *** 685,691 **** if (regno != -1) { /* Not writing all the regs */ /* save new register value */ ! char old_value[REGISTER_SIZE]; memcpy (old_value, ®isters[REGISTER_BYTE (regno)], REGISTER_SIZE); val = p_td_thr_getgregs (&thandle, gregset); --- 685,691 ---- if (regno != -1) { /* Not writing all the regs */ /* save new register value */ ! char* old_value = (char*) alloca (REGISTER_SIZE); memcpy (old_value, ®isters[REGISTER_BYTE (regno)], REGISTER_SIZE); val = p_td_thr_getgregs (&thandle, gregset); Index: gdb/valops.c =================================================================== RCS file: /cvs/src/src/gdb/valops.c,v retrieving revision 1.30 diff -c -3 -p -r1.30 valops.c *** valops.c 2001/02/06 18:07:48 1.30 --- valops.c 2001/02/06 19:52:58 *************** value_assign (register value_ptr toval, *** 570,576 **** { register struct type *type; register value_ptr val; ! char raw_buffer[MAX_REGISTER_RAW_SIZE]; int use_buffer = 0; if (!toval->modifiable) --- 570,576 ---- { register struct type *type; register value_ptr val; ! char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE); int use_buffer = 0; if (!toval->modifiable) *************** CORE_ADDR *** 1027,1033 **** push_word (CORE_ADDR sp, ULONGEST word) { register int len = REGISTER_SIZE; ! char buffer[MAX_REGISTER_RAW_SIZE]; store_unsigned_integer (buffer, len, word); if (INNER_THAN (1, 2)) --- 1027,1033 ---- push_word (CORE_ADDR sp, ULONGEST word) { register int len = REGISTER_SIZE; ! char *buffer = alloca (MAX_REGISTER_RAW_SIZE); store_unsigned_integer (buffer, len, word); if (INNER_THAN (1, 2)) *************** You must use a pointer to function type *** 1665,1671 **** SAVE_DUMMY_FRAME_TOS (sp); { ! char retbuf[REGISTER_BYTES]; char *name; struct symbol *symbol; --- 1665,1671 ---- SAVE_DUMMY_FRAME_TOS (sp); { ! char *retbuf = (char*) alloca (REGISTER_BYTES); char *name; struct symbol *symbol; Index: gdb/config/sparc/sun4sol2.mh =================================================================== RCS file: /cvs/src/src/gdb/config/sparc/sun4sol2.mh,v retrieving revision 1.3 diff -c -3 -p -r1.3 sun4sol2.mh *** sun4sol2.mh 2000/10/24 20:05:36 1.3 --- sun4sol2.mh 2001/02/06 19:52:58 *************** NAT_FILE= nm-sun4sol2.h *** 8,13 **** --- 8,16 ---- NATDEPFILES= corelow.o core-sol2.o solib.o solib-svr4.o fork-child.o procfs.o \ proc-api.o proc-events.o proc-flags.o proc-why.o + # /usr/include/v9 is needed only by core-sol2.c when including + # v9/sys/privregs.h, or rather the headers it in turn includes. + MH_CFLAGS=-I/usr/include/v9 # If you are compiling with Sun's compiler, add the -xs option to CC # (e.g. `make CC="cc -xs"'). # Sun's compilers require the -xs option to produce debug information *************** NATDEPFILES= corelow.o core-sol2.o solib *** 15,19 **** # files only, with undocumented pointers to it in the linked executable. # This is commented out because we don't assume that the Sun compiler # is in use. ! #MH_CFLAGS=-xs HOST_IPC=-DBSD_IPC --- 18,22 ---- # files only, with undocumented pointers to it in the linked executable. # This is commented out because we don't assume that the Sun compiler # is in use. ! #MH_CFLAGS=-xs -I/usr/include/v9 HOST_IPC=-DBSD_IPC >From philb@gnu.org Tue Feb 06 12:14:00 2001 From: Philip Blundell To: "Scott Bambrough" Cc: "Michael Snyder" , "Mark Kettenis" , gdb-patches@sources.redhat.com Subject: Re: patch for ARM GNU/Linux Date: Tue, 06 Feb 2001 12:14:00 -0000 Message-id: References: <3A7F0B3A.1D1B33B3@cygnus.com> <01f401c08fca$055387e0$LocalHost@netbackup> X-SW-Source: 2001-02/msg00084.html Content-length: 64 >This patch is ok with me. Thanks. I've checked it in. p.