Re: Strange Behavior When Looking for Hex Values
Re: Strange Behavior When Looking for Hex Values
- Subject: Re: Strange Behavior When Looking for Hex Values
- From: Joe van Tunen <email@hidden>
- Date: Tue, 02 Oct 2007 10:52:11 -0700
- Thread-topic: Strange Behavior When Looking for Hex Values
Power PC instructions are all 4 bytes long so it could take two instructions
to load a 4 byte value into a register. The instructions are not always next
to each other or in the same order or the same instruction. The 4 bytes may
not appear in the code at all. For example, loading 0xDEADBEEF into register
r3 could look like this:
3C60DEAE lis r3,-8530 <-- loads 0xDEAE instead of 0xDEAD
... <-- any number of instructions here
3863BEEF subi r3,r3,16657 <-- finish loading r3
You should download a Motorola PowerPC instruction manual (like "PowerPC
601 RISC Microprocessor User's Manual" or a "Programming Environments"
manual).
You need something like the objdump (or gobjdump) or otool command line
tools to examine a binary file properly. They can dump the various sections
of the binary file and disassemble the code sections.
> From: James Kelly <email@hidden>
> Date: Tue, 02 Oct 2007 09:37:31 -0400
> To: <email@hidden>
>
> Well, this behavior is strange to me at least, and my co-workers seem a bit
> surprised as well. I'm willing to entertain the idea that we are missing
> something fundamental, however (in fact, I'd say that's the only way to
> explain this).
>
> I am searching for a series of hex values in a binary file, they are defined
> as two Uint32s. On the intel side of the universal binary, they can be
> searched for as expected, using a hex editor for example. When looking at
> the ppc code, expecting to see the values reversed, we don't find them as
> their whole Uint32 selves, but broken up. Interestingly enough, they are
> broken into smaller pieces and interwoven with each other. An example would
> probably better explain. Say my hex values were as follows (for
> simplicity's sake, we'll assume these are already in the ppc byteorder):
>
> 0x12345678
> 0x9ABCDEF0
>
> In the ppc side of the code, the values will be found like so (using 00 to
> represent random fill-in values):
>
> 12 34 00 00 9A BC 00 00 56 78 00 00 DE F0
>
> So as you can see, the first four hex digits from the first value, then four
> unrelated hex digits, then the first four hex digits from the second value,
> then four unrelated hex digits, then the last four hex digits from the first
> value, and so on.
>
> Is this the way it is supposed to be? Is there anyone who could point me to
> a resource to read up on this behavior and similar issues? Thanks in
> advance. And I apologize for the verbosity, I just wanted to be clear on
> the problem.
>
> Jim
>
****************************************************************************
This email may contain material confidential to
Pearson. If you were not an intended recipient,
please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden