site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcgE+WGMoBGBjHDsEdyz+wADk61ysgAI5OVY Thread-topic: Strange Behavior When Looking for Hex Values User-agent: Microsoft-Entourage/11.3.6.070618 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 <JKelly@nemetschek.net> Date: Tue, 02 Oct 2007 09:37:31 -0400 To: <darwin-dev@lists.apple.com>
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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com