Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Pedro Alves'" <pedro_alves@portugalmail.pt>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90
Date: Mon, 24 Sep 2007 06:57:00 -0000	[thread overview]
Message-ID: <005d01c7fe78$309525c0$91bf7140$@u-strasbg.fr> (raw)
In-Reply-To: <46F486B4.6050900@portugalmail.pt>

  

> -----Original Message-----
> From: Pedro Alves [mailto:alves.ped@gmail.com] On Behalf Of Pedro Alves
> Sent: Saturday, September 22, 2007 5:06 AM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90
> 
> Hi,
> 
> This afects Cygwin badly, as it still uses stabs by default.
> I've seen this problem here, but thought it was caused by a few gcc
> changes I was making ...
> 
> Pierre Muller wrote:
> >   As I was unable to understand the current implementation of the
> > twos_complement_representation
> 
> I can't really see how it was supposed to work either.
> Parsing 000000000 is broken currently.
> 
> > I rewrote it almost completely.
> 
> You are only counting the bits.  This function should return the parsed
> number if it fits in a long:

  My idea was to clear the sign bit and
let the normal code handle the parsing of the value,
but I completely forgot that two complement notation
is not the same as the multiplication by -1.
  So I should probably have let the sign bit and parse it
as an unsigned integer.


> /* If TWOS_COMPLEMENT_BITS is set to a strictly positive value and if
>      the number is represented in an octal representation, assume that
>      it is represented in a 2's complement representation with a size
> of
>      TWOS_COMPLEMENT_BITS.
> 
>      If the number fits in a long, set *BITS to 0 and return the value.
>      If not, set *BITS to be the number of bits in the number and
> return 0.
> 
>      If encounter garbage, set *BITS to -1 and return 0.  */
> 
> 
> >   The code now checks that the most significant bit of the whole
> octal
> > representation of the huge number that is being parsed is exactly at
> > the bit position given by the twos_complement_bits parameter.
> >
> 
> >   The attached patch (against 6.6.90 source) fixes the problem that I
> > describe in the previous email. I get no complaint for the 'unsigned
> > long long' type compiled with '-gstabs+' option.
> >
> 
> Thanks for pointing in the right direction!
> 
> (Forgive me for counter patching, but I had started on this
>   here too yesterday :( )

 As nobody reacted on my first email,
I thought that nobody cared.
  I am glad you propose a new patch.
As you already proposed a second one,
I will try to comment on that one directly.

Thanks

Pierre Muller



      parent reply	other threads:[~2007-09-24  6:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000e01c7fb9b$22e600f0$68b202d0$@u-strasbg.fr>
2007-09-21  8:01 ` Pierre Muller
2007-09-22  3:07   ` Pedro Alves
2007-09-22  4:20     ` Joel Brobecker
2007-09-22 10:17       ` Pedro Alves
2007-09-22 19:39     ` Pedro Alves
2007-09-22 22:58       ` Joel Brobecker
2007-09-22 23:08         ` Daniel Jacobowitz
2007-09-23  1:17           ` Joel Brobecker
2007-09-23 10:17             ` Pedro Alves
2007-09-23 11:39           ` Pedro Alves
2007-09-23 12:42             ` Daniel Jacobowitz
2007-09-23 13:57               ` Pedro Alves
2007-09-24  0:43       ` Pedro Alves
2007-09-24  9:15         ` Pierre Muller
2007-09-24 10:21           ` Pedro Alves
2007-09-24 13:30             ` Pierre Muller
2007-09-25  8:09               ` Pedro Alves
2007-09-25 23:58                 ` Pedro Alves
2007-10-03 12:06                   ` Pierre Muller
2007-10-03 16:43                     ` Jim Blandy
2007-10-03 18:44                     ` Joel Brobecker
2007-10-03 18:51                       ` Daniel Jacobowitz
2007-10-03 19:07                         ` Joel Brobecker
2007-10-03 21:36                         ` Pedro Alves
2007-10-03 21:40                           ` Daniel Jacobowitz
2007-10-05  9:59                             ` Pedro Alves
2007-10-08 23:26                               ` Pedro Alves
2007-10-09  9:10                                 ` Pierre Muller
2007-10-09 11:39                                   ` Pedro Alves
2007-09-23  1:06     ` Joel Brobecker
2007-09-24  6:57     ` Pierre Muller [this message]

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='005d01c7fe78$309525c0$91bf7140$@u-strasbg.fr' \
    --to=muller@ics.u-strasbg.fr \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro_alves@portugalmail.pt \
    /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