Re: [cdt-dev] DSF GdbMemoryBlock endianness detection proposal

[John Dallaway <john@xxxxxxxxxxxxxxx>]

Hi Marc

Thank you for your response.

The change I am proposing is small (certainly less than 250 lines) and
non-invasive. There would be no API breakage - just a couple of new
constructors which are used internally. This is really more of a fix
than a new feature. The only effect will be that MemoryByte objects will
be marked with correct endianness rather than always being marked little
endian. In my experiments, this appears to be of little consequence for
the rest of CDT other than ensuring that the default presentation of
memory words in various memory renderers is correct for both big-endian
and little-endian targets.

I would welcome some confirmation that the approach is a reasonable one
from anyone qualified to comment. Otherwise, I will proceed with
implementation and submit a patch for consideration in due course.

John Dallaway


-------- Original Message --------
Subject: Re: [cdt-dev] DSF GdbMemoryBlock endianness detection proposal
Date: Thu, 8 Mar 2012 13:07:03 -0500
From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
To: 'CDT General developers list.' <cdt-dev@xxxxxxxxxxx>
References: <4F58F2F2.1060501@xxxxxxxxxxxxxxx>

Hi John,

thanks for the contribution proposal.

I personally don't have much experience with the memory feature,
so if no one else can help you, I will need to set some time
aside to get ramped-up.  I don't think that will be possible
for the Juno timeframe for me.

If someone else can help, please be aware that:
1- CQ deadline is passed, so any contribution > 250 lines will
be tricky to accept for Juno
2- API freeze for Juno is M6, March 23rd (2 weeks).   However,
if needed and if no one objects, we usually accept changes until
M7 (May 11th).
3- No API breakage is allowed for Juno (CDT 8.1)

I just want to make sure you have realistic expectations about
getting this into Juno.  Time has flown hasn't it.
But if not Juno, Kepler is right behind.

Marc


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Dallaway
> Sent: Thursday, March 08, 2012 12:57 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] DSF GdbMemoryBlock endianness 
> detection proposal
> 
> CDT team
> 
> Are there any comments on this proposal before I start on the
> implementation? I would be intending to contribute this as a 
> patch for Juno.
> 
> John Dallaway
> 
> 
> -------- Original Message --------
> Subject: [cdt-dev] DSF GdbMemoryBlock endianness detection proposal
> Date: Mon, 05 Mar 2012 09:29:19 +0000
> From: John Dallaway <john@xxxxxxxxxxxxxxx>
> Reply-To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> To: cdt-dev@xxxxxxxxxxx
> 
> CDT team
> 
> I've been looking at the DSF-GDB memory block implementation 
> with a view
> to presenting memory words with correct endianness in the 
> Memory view by
> default. First, a couple of observations:
> 
> a) The current implementation of 
> MIDataReadMemoryInfo.parseMemoryLines()
> always creates MemoryByte objects with the default flags (including
> ENDIANESS_KNOWN and excluding BIG_ENDIAN). This is clearly not correct
> when the target is big endian.
> 
> b) The CDT traditional memory rendering code uses the 
> endianness of the
> zeroth byte of a MemoryBlock to determine whether to default to a big
> endian or little endian presentation. This behaviour seems reasonable.
> 
> My proposal is to implement alternative DSF MIDataReadMemory and
> MIDataReadMemoryInfo constructors that take a MemoryByte flag as a
> parameter. This flag would then be used to set the MemoryByte object
> endianness correctly. The original behaviour would be preserved when
> using the original constructors so there would be no 
> compatibility issues.
> 
> The target endianness could be retrieved at the DSF MIMemory service
> level using a GDB "show endian" command just before the first memory
> block read and then passed to MIDataReadMemory using the new
> constructor. The endianness information could be cached within the DSF
> MIMemory object so would be retrieved only once per session.
> 
> Would a patch along these lines be acceptable to the CDT committers?
> 
> John Dallaway