From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30046 invoked by alias); 26 Sep 2005 04:46:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30025 invoked by uid 22791); 26 Sep 2005 04:46:08 -0000 Received: from mta09-winn.ispmail.ntl.com (HELO mta09-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 26 Sep 2005 04:46:08 +0000 Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20050926044606.GVH9239.mta09-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>; Mon, 26 Sep 2005 05:46:06 +0100 Received: from [127.0.0.1] (really [81.108.244.65]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20050926044605.OGHE13031.aamta09-winn.ispmail.ntl.com@[127.0.0.1]>; Mon, 26 Sep 2005 05:46:05 +0100 Message-ID: <43377D19.7050505@ntlworld.com> Date: Mon, 26 Sep 2005 04:46:00 -0000 From: Dave Murphy User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [patch] Build arm-elf-gdb on mingw host References: <4337317B.3050300@ntlworld.com> <20050926035937.GA24565@nevyn.them.org> In-Reply-To: <20050926035937.GA24565@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0538-7, 23/09/2005), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2005-09/txt/msg00217.txt.bz2 Daniel Jacobowitz wrote: >On Mon, Sep 26, 2005 at 06:46:10AM +0300, Eli Zaretskii wrote: > > >>>When building the bfd/doc directory under mingw/msys chew.c converts >>>line endings to crlf. I've patched so the files are read as binary, >>>preventing this conversion. >>> >>> >>Why? What's wrong with having the output from chew have CRLF line >>endings on Windows? >> >> > >Yeah, I'm wondering about this too. > > > Sorry, I should have said that under mingw/msys files read in text mode have line endings converted. There are numerous places in chew.c where it checks for a newline character with expressions like "while (at (tos, idx) == '\n')", see skip_white_and_stars(src, idx), strip_trailing_newlines(), remove_noncomments (src, dst), outputdots(), courierize(), bulletize(), copy_past_newline (ptr, idx, dst), kill_bogus_lines(), indent(), skip_past_newline () and nextword (string, word). It seemed easier to just read the input files as binary and suppress the conversion rather than make all the code deal with the "/r/n" sequence. Without the supression we get the following error when building in bfd/doc ./chew.exe -f ../../../../gdb/bfd/doc/doc.str <../../../../gdb/bfd/doc/../mmo.c >mmo.tmp /bin/sh ../../../../gdb/bfd/doc/../../move-if-change mmo.tmp mmo.texi restore=: && backupdir=".am$$" && \ am__cwd=`pwd` && cd ../../../../gdb/bfd/doc && \ rm -rf $backupdir && mkdir $backupdir && \ for f in ../../../../gdb/bfd/doc/bfd.info ../../../../gdb/bfd/doc/bfd.info-[0-9] ../../../../gdb/bfd/doc/bfd.info-[0-9][0-9] ../../../../gdb /bfd/doc/bfd.i[0-9] ../../../../gdb/bfd/doc/bfd.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ cd "$am__cwd"; \ if makeinfo --split-size=5000000 -I ../../../../gdb/bfd/doc \ -o ../../../../gdb/bfd/doc/bfd.info ../../../../gdb/bfd/doc/bfd.texinfo; \ then \ rc=0; \ cd ../../../../gdb/bfd/doc; \ else \ rc=$?; \ cd ../../../../gdb/bfd/doc && \ $restore $backupdir/* `echo "./../../../../gdb/bfd/doc/bfd.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc section mapping'.ss reference to nonexistent node `mmo a New Hash Table Type'.ference to nonexistent node `Deriving makeinfo: Removing output file `../../../../gdb/bfd/doc/bfd.info' due to errors; use --force to preserve. make[2]: *** [../../../../gdb/bfd/doc/bfd.info] Error 2 This is due to @xref{mmo section mapping}.crossing a line boundary on line 67 of mmo.c >>>SIGTRAP isn't defined in the MinGW headers, I patched remote-sim.c to >>>define this if it's not defined. >>> >>> >>I don't think this is a good idea. It is much better (and widely >>practiced) to #ifdef away portions of code that use SIGTRAP, like >>this: >> >> #ifdef SIGTRAP >> ... code that depends on SIGTRAP ... >> #endif >> >> > >In this case, unfortunately, it's a bit more complicated to fix. You >can find a similar workaround patch from Paul Brook in the archives, >and my discussion (with Mark?) about it. The gdb<->sim interface uses >"signals", meaning the host signal numbers. And without SIGTRAP we >can't step or breakpoint. Thus, a lot of files in sim already define >SIGTRAP. > >They ought to be converted to the relatively new "gdb/signals.h" header >in include/, but the simulators are also concerned with actual host >signals in places, so a simple search and replace isn't right either. >It's going to take a little investigation to fix this properly. > > > From a brief look at the sources it appeared to me that it was a signal being passed internally between gdb and the simulator. I'll have a look for the previous discussions. Dave