This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Build arm-elf-gdb on mingw host

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/ ../../../../gdb/bfd/doc/[0-9] ../../../../gdb/bfd/doc/[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/ ../../../../gdb/bfd/doc/bfd.texinfo; \
then \
rc=0; \
cd ../../../../gdb/bfd/doc; \
else \
rc=$?; \
cd ../../../../gdb/bfd/doc && \
$restore $backupdir/* `echo "./../../../../gdb/bfd/doc/" | 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/' due to errors; use --force to preserve.
make[2]: *** [../../../../gdb/bfd/doc/] 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

#ifdef SIGTRAP
... code that depends on SIGTRAP ...

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]