Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Tim Auton <tim.auton@uton.org>
Cc: gdb-patches@sourceware.org
Subject: Re: Remote Debugging Protocol - hex case
Date: Tue, 13 Feb 2007 22:49:00 -0000	[thread overview]
Message-ID: <20070213224921.GA25525@caradoc.them.org> (raw)
In-Reply-To: <842A2789-AFD7-4339-8E5E-608D6C9CFDD7@uton.org>

On Tue, Feb 13, 2007 at 09:45:41PM +0000, Tim Auton wrote:
> As far as I can see, making remote debugging support upper-case hex
> properly won't be much trouble. It pretty much amounts to replacing the
> disparate error checking in remote.c with calls to
> packet_check_result(). But it's quite possible that I'm missing wider
> repercussions which are obvious to someone who knows GDB and the source
> much better than me (which is probably most of you).

As far as I know, you are correct - it's just a matter of cleanup.
The "more correct" functions you mention are much newer, and it's hard
to test some of the older bits of the file - that's why not much has
happened.

> 1) Patch remote.c to support upper-case hex consistently, update docs to
> suggest lower-case for backward compatibility.
> 
> 	Pros: Consistent with the rest of GDB, which generally supports
> 	upper-case hex.
> 
> 	Cons: Any stubs which don't provide a two-digit errno or a 
> 	E.something
> 	string will break. (Do any exist?)

I think they are sufficiently broken that we should not bend over
backwards to support them (though recognizing "ENN" as an error might
be useful - a recent PR was at least the second time I've seen someone
do that.)

> I'm happy to write and submit the patches once the maintainers decide on
> the best course of action, though as I'm not intimate with GDB's
> internals and don't (yet) have the first clue about texinfo (but am
> wiling to learn), the maintainers may wish to be more circumspect than
> ususal in checking them. I've found the GNU coding standards, but
> pointers to anything else relevant would be well received (off-list, if
> appropriate).

That, and the list archives, should be fine as references.  I'd be
glad to review patches in this area.  Please note that this would be
non-trivial work, so it would require an FSF copyright assignment for
GDB - let me know if you're able and willing to do that (or have one
already).

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2007-02-13 22:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-13 21:45 Tim Auton
2007-02-13 22:49 ` Daniel Jacobowitz [this message]
2007-02-14 16:26   ` Tim Auton
2007-02-14 16:41     ` 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=20070213224921.GA25525@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tim.auton@uton.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