This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/194
- To: nobody at sources dot redhat dot com
- Subject: Re: gdb/194
- From: "Tom Taylor" <ttaylor at ateng dot com>
- Date: 5 Oct 2001 15:28:00 -0000
- Cc: gdb-prs at sources dot redhat dot com,
- Reply-To: "Tom Taylor" <ttaylor at ateng dot com>
The following reply was made to PR gdb/194; it has been noted by GNATS.
From: "Tom Taylor" <ttaylor@ateng.com>
To: <araes@netzero.net>,
<nobody@sources.redhat.com>,
<gdb-gnats@sources.redhat.com>,
<gdb-prs@sources.redhat.com>
Cc:
Subject: Re: gdb/194
Date: Fri, 5 Oct 2001 11:26:19 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_09C4_01C14D90.8DEEEE80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I ran into the same "missing position field" problem with the PSIM =
ppc-instructions file while building the powerpc-unknown-eabi version of =
Insight/GDB 5.0 using Cygwin 1.3.1 under WinNT. =20
When WinZIP is used to unpack the tar files, it evidently converts =
source files to use DOS line endings. While I haven't had a problem =
anywhere else with this, the parser of the ppc-instructions file is =
written to look only for explicit newlines in a memory image of the =
file. The carriage returns confuse it so it gets out of sync. =20
The simple fix is to convert ppc-instructions to use Unix line endings. =
Later on, it would be nice to fixup the code in table.c so that either =
the line-endings are standardized when the file is loaded into memory, =
or the parser can accept <CR> only (Mac), <LF> only (Unix), or <CR><LF> =
(Win/DOS) as line-endings. The easiest approach may be to change the =
file open mode in table.c:table_open() to include O_TEXT, but I haven't =
tried this yet.
-- Tom Taylor, Taylor Consulting Services
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=3Dview%26pr=3D194%26dat=
abase=3Dg
------=_NextPart_000_09C4_01C14D90.8DEEEE80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><FONT face=3DArial size=3D2>I ran into the same "missing position =
field" problem=20
with the PSIM ppc-instructions file while building the =
powerpc-unknown-eabi=20
version of Insight/GDB 5.0 using Cygwin 1.3.1 under WinNT. =
</FONT></P>
<P><FONT face=3DArial size=3D2>When WinZIP is used to unpack the tar =
files, it=20
evidently converts source files to use DOS line endings. While I =
haven't=20
had a problem anywhere else with this, the parser of the =
ppc-instructions file=20
is written to look only for explicit newlines in a memory image of the=20
file. The carriage returns confuse it so it gets out of =
sync. =20
</FONT></P>
<P><FONT face=3DArial size=3D2>The simple fix is to convert =
ppc-instructions to use=20
Unix line endings. Later on, it would be nice to fixup the code in =
table.c=20
so that either the line-endings are standardized when the file is loaded =
into=20
memory, or the parser can accept <CR> only (Mac), <LF> only =
(Unix),=20
or <CR><LF> (Win/DOS) as line-endings. The easiest =
approach=20
may be to change the file open mode in table.c:table_open() to=20
include O_TEXT, but I haven't tried this yet.</FONT></P>
<P><FONT face=3DArial size=3D2>-- Tom Taylor, Taylor Consulting=20
Services</FONT></P><A=20
href=3D"http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=3Dview%26pr=3D1=
94%26database=3Dg">http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=3Dvi=
ew%26pr=3D194%26database=3Dg</A></BODY></HTML>
------=_NextPart_000_09C4_01C14D90.8DEEEE80--