Re: Remote Debugging Protocol - hex case

[Tim Auton <tim.auton@uton.org>]

On 13 Feb 2007, at 22:49, Daniel Jacobowitz wrote:
> 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.

OK, I'll have a good look at the testing framework and see what's  
there at
present.

>> 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.)

Can I take it that means option 1 looks most desirable?

>> 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).

I don't have one, but FSF copyright assignment is no problem to me and
there's no legal impediment. I presume you'll let me know exactly what
I need to do to sort the papers out.


Tim