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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>