Sorry I didn't explain that very well -- this snippet of data explains
the problem better!
0x00001150 36323a39 353a3431 202c3330 30322036 6 2003, 14:59:26
0x00001160 ff80d0f2 0036ff80 d0f21204 12050000 ..........6.....
0x00001170 41304135 41340035 ffc2007f 407f0035 5...@...5.4a5a0a
If you look at the top line the ascii is fine but the data section goes
from left to right! The data address of 0x1150e is 0x20, a space (' ')
character, but there is no space character in the last 8 bytes of the
string... Maybe the endian-ness is 64 bits?
Also get this for a data section:
Hex dump of section '.data':
0x00000200 00000078 00002638 00000000 00fe0000 ........8&..x...
0x00000210 00000000 00000000 00000000 00000000 ................
0x00000220 00000000 00000000 00000f00 00000000 ................
0x00000230 00010000 00000000 00000000 00000000 ................
0x00000240 413023fe 831f4130 0A...#0A
Note at the end the data section is right justified but the ascii
section is left. Is this correct?
Sorry to be so irritating but I want to write a script to pull some
information out of the built file for production purposes and it is a
bit hard getting it all to hang toghter...
Thanks
Tim
> -----Original Message-----
> From: Chris Liechti [mailto:cliec...@gmx.net]
> Sent: Friday, 17 October 2003 2:25 AM
> To: mspgcc-users@lists.sourceforge.net
> Subject: Re: [Mspgcc-users] Something odd in msp430-readelf
>
>
> Tim Wade wrote:
> > Hi I was using the msp430-readelf program to check a few things and
> > noticed that if you do a --hex-dump=? Then you get the expected hex
> > dump but the hex values on the left seem to be back to
> front.... For
> > example:
> >
> > Hex dump of section '.text':
> > 0x00001100 403d0200 403e5256 403f0120 5a8040b2 ....@.z ....@vr>@..=@
> > 0x00001110 2bfb9d0e 531e0000 4ffe2405 9e0d024c L....$.O...S...+
> >
> > The string bit on the right seems to be correct but if you Look
> > carefully at the hex values you will notice that they are
> Flipped left
> > to right ie in our case the hex value of 0x40 should Be at address
> > 0x110f NOT 0x1100
> >
> > This wouldn't appear to be correct?
>
> thats fine. look up the difference between "little endian" and "big
> endian" byte order. the MSP430 is little endian.
>
> a hex dump with byte swapped 32bit ints doesnt make much
> sense for the
> MSP430, but if you switch the output format to 16bit ints,
> its the same
> as the processor sees when accessing 16bit values. i'm sure
> you can also
> switch to a eight bit hex dump, which would show the bytes in
> the same
> order as the ascii dump on the right.
>
> chris
--
This email is confidential and intended solely for the use of the individual to
whom it is addressed. Any views or opinions presented are solely those of the
author and do not necessarily represent those of Nautronix Ltd.
If you are not the intended recipient, you have received this email in error
and use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited. If you have received this email in error please contact
the sender.
Although our computer systems use active virus protection software, and we take
various measures to reduce the risk of viruses being transmitted in e-mail
messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt. It is a
condition of our using e-mail to correspond with you, that any and all
liability on our part arising directly or indirectly out of any virus is
excluded.
Please ensure that you run virus checking software on all e-mail messages and
attachments before reading them.
