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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

I haven't looked into the different solutions, but
I agree that using GDB should be done when possible.

Marc 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Giuseppe MONTALTO
> Sent: Monday, March 12, 2012 8:39 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] DSF GdbMemoryBlock endianness 
> detection proposal
> 
> Hi all!
> 
> What about querying GDB for the endianess, instead of inspecting the 
> memory block contents?
> 
> Using the "show endian" GDB CLI command (or its MI equivalent) should 
> be safer, especially when dealing with bi-endian targets, like SH, 
> MIPS, PowerPC...
> 
> Ciao,
> 	Giuseppe Montalto
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of John Dallaway
> > Sent: Thursday, March 08, 2012 8:29 PM
> > To: Marc Khouzam
> > Cc: cdt-dev@xxxxxxxxxxx
> > Subject: Re: [cdt-dev] DSF GdbMemoryBlock endianness 
> detection proposal
> > 
> > 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
> > 
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>