From: "Alexander Aganichev" <AAganichev@hypercom.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: binutils@sourceware.cygnus.com
Subject: Re: IEEE support issues
Date: Sun, 02 Jul 2000 22:29:00 -0000 [thread overview]
Message-ID: <OFA030A7C8.16DAF90F-ONC3256911.001CA430@hypercom.com> (raw)
Oops, you're right. I've just been confused to know that Changelogs in
tarball binutils-000627.tar.bz2 on sourceware.cygwin.com mirrors dated
with... end of May though archive isn't. Anyone have ideas?
--
Alexander Aganichev
Hypercom Europe Limited, Inc.
Software Engineer
Alan Modra
<alan@linuxca To: Alexander Aganichev <AAganichev@hypercom.com>
re.com.au> cc: binutils@sourceware.cygnus.com
Subject: Re: IEEE support issues
01.07.2000
14:00
On Sat, 1 Jul 2000, Alexander Aganichev wrote:
> 1. This code in ieee.c was fixed in CVS but then reverted:
No, your patch of 2000-06-20 wasn't reverted. It was the incorrect
2000-06-25 patch to ar.c and bucomm.c that I reverted.
> 2. The second issue I found is that GCC and Binutils differently parses
> size in .stab debug information: GCC produces sizes in bits and Binutils
> assumes bytes. I don't know who is right (though it seems like GCC) but
> this issue should be resolved. Currently I've added division by 8 to the
> parse_stab_type() (stabs.c) as follows:
Thanks for debugging this. Your patch looks OK to me, but in future
please provide patches using "diff -up" along with a plain text changelog
entry like the example below. Changing binutils internal debug structures
to store size in bits is probably more correct, but a much larger change.
I'll check in the following:
binutils/ChangeLog
2000-07-01 Alexander Aganichev <AAganichev@hypercom.com>
* stabs.c (parse_stab_type): Divide size in bits by 8 as
binutils
struct debug_type stores size in bytes.
Index: stabs.c
===================================================================
RCS file: /cvs/src/src/binutils/stabs.c,v
retrieving revision 1.4
diff -u -p -r1.4 stabs.c
--- stabs.c 2000/01/14 23:10:21 1.4
+++ stabs.c 2000/07/01 09:38:33
@@ -1261,6 +1261,7 @@ parse_stab_type (dhandle, info, typename
{
case 's':
size = atoi (attr + 1);
+ size /= 8; /* Size is in bits. We store it in bytes. */
if (size <= 0)
size = -1;
break;
--
Linuxcare. Support for the Revolution.
next reply other threads:[~2000-07-02 22:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-02 22:29 Alexander Aganichev [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-07-01 1:17 Alexander Aganichev
2000-07-01 3:00 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OFA030A7C8.16DAF90F-ONC3256911.001CA430@hypercom.com \
--to=aaganichev@hypercom.com \
--cc=alan@linuxcare.com.au \
--cc=binutils@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).