Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top