Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb@sourceware.org
Subject: Re: GDB transition to GPLv3 should now be complete
Date: Fri, 24 Aug 2007 16:54:00 -0000	[thread overview]
Message-ID: <20070824165439.GA782@caradoc.them.org> (raw)
In-Reply-To: <200708241616.l7OGGOhD010090@brahms.sibelius.xs4all.nl>

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.

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.

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.

> 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

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2007-08-24 16:54 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 [this message]
2007-08-24 18:11         ` Mark Kettenis
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=20070824165439.GA782@caradoc.them.org \
    --to=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