Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb@sourceware.org
Subject: Re: GDB transition to GPLv3 should now be complete
Date: Fri, 24 Aug 2007 18:11:00 -0000	[thread overview]
Message-ID: <200708241811.l7OIBHnO027640@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20070824165439.GA782@caradoc.them.org> (message from Daniel 	Jacobowitz on Fri, 24 Aug 2007 12:54:39 -0400)

> Date: Fri, 24 Aug 2007 12:54:39 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Aug 24, 2007 at 06:16:25PM +0200, Mark Kettenis wrote:
> > 1. There is quite a bit of code that uses "unsigned char *" for
> >    strings, to avoid unwanted sign extension.
> 
> This is the real question, yes.  I've made it even easier to view
> these as strings if desired.  I've asked several times if the changes
> were good enough.  I think I got a generally affirmative reaction, but
> it's hard to tell.

Well, the problem with this diff is that it actually seems to be a
good idea until you actually start to use it.  I thought it was a good
idea, so I put it in my tree.  And I threw it out again after a few
days because I was annoyed by the fact that it didn't print strings as
strings in many cases where I was sure it did before.  As I said, the
use of "unsigned char *" is very common in string manipulation code.

> We can't be right by default all the time, since there just isn't
> enough information.  What I'm suggesting is that the new behavior will
> be right more often than the old behavior.  I have worked with a
> variety of high performance computing and signal processing
> developers who are interested in unsigned single-byte data.

Yes, I can imagine that, but these people are working in fairly
specialized areas with specific requirements.

> If you're already using user-defined commands to print data, by the
> way, the difference is a non-issue.  I believe that covers much of
> the Emacs case.

But the developers you talk about above can easily do the same.  And
when I'm not specifically talking about Emacs when I talk about code
that does string manipulations.

> > 2. Not all debug formats (most notably stabs) do not make the
> >    distinction between unqualified "char" and "(un)signed char".
> 
> That does not seem to be correct, at least in the case of stabs.  Even
> with -gstabs (i.e. without GNU extensions to stabs), GDB correctly
> sets the NOSIGN and UNSIGNED flags for char variants (example below).
> I also checked the "maint print type" output and NOSIGN is set where
> I'd expect.  And it already gets set for types whose name is char in
> init_type; this also handles all typedefs to char, et cetera, as long
> as your debug format represents typedefs.  I admit it will leave
> "typedef char char_t" users having to type a couple extra characters
> to get a string if they're using mdebug...
> 
> I did find a bug in the stabs reader testing this, though.  It
> bypasses the NOSIGN check because it creates the type and then sets
> TYPE_NAME later.  Easy to fix.
> 
> drow@caradoc:~% cat foo.c
> char c;
> signed char d;
> unsigned char e;
> int main(){}
> 
> drow@caradoc:~% gcc -gstabs foo.c
> drow@caradoc:~% gdb ./a.out
> GNU gdb 6.6-debian
> ...
> (gdb) ptype c
> type = char
> (gdb) ptype d
> type = signed char
> (gdb) ptype e
> type = unsigned char

Ah, that fix would be very welcome.  Need to verify this with GCC
2.95.3 though.


  reply	other threads:[~2007-08-24 18:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-24 15:08 Joel Brobecker
2007-08-24 15:28 ` Mark Kettenis
2007-08-24 15:33   ` Daniel Jacobowitz
2007-08-24 16:16     ` Mark Kettenis
2007-08-24 16:54       ` Daniel Jacobowitz
2007-08-24 18:11         ` Mark Kettenis [this message]
2007-08-24 18:40           ` Daniel Jacobowitz
2007-08-24 22:17             ` Daniel Jacobowitz
2007-08-25  9:36               ` Eli Zaretskii
2007-08-25 13:39                 ` Daniel Jacobowitz

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=200708241811.l7OIBHnO027640@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    /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