Page MenuHomeFreeBSD

fix libproc for big-endian systems
ClosedPublic

Authored by br on Oct 14 2016, 2:24 PM.

Details

Summary

use uint32_t for instruction storage. This fixes operation on big endian 64bit MIPS

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

br updated this revision to Diff 21389.Oct 14 2016, 2:24 PM
br retitled this revision from to fix libproc for big-endian systems.
br updated this object.
br edited the test plan for this revision. (Show Details)
br added a reviewer: rpaulo.
rpaulo edited edge metadata.Oct 15 2016, 5:20 AM

I don't think this is right. Not all big endian systems are LP64.

br added a comment.Oct 18 2016, 1:59 PM

I don't think this is right. Not all big endian systems are LP64.

why? I bet it should work with any sizeof(unsigned long), e.g. 4 or 8

In D8250#172166, @br wrote:

I don't think this is right. Not all big endian systems are LP64.

why? I bet it should work with any sizeof(unsigned long), e.g. 4 or 8

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

br added a comment.Oct 18 2016, 4:59 PM

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

In D8250#172233, @br wrote:

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

Then how is it reading the original instruction correctly?

br added a comment.Oct 19 2016, 10:54 AM
In D8250#172233, @br wrote:

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

Then how is it reading the original instruction correctly?

it reads the correct value, e.g. 0x67bdfff000000000. Casting it to uint32_t gives us 0x67bdfff0.

br updated this revision to Diff 21492.Oct 19 2016, 10:54 AM
br edited edge metadata.

here is another one possible solution

In D8250#172346, @br wrote:
In D8250#172233, @br wrote:

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

Then how is it reading the original instruction correctly?

it reads the correct value, e.g. 0x67bdfff000000000. Casting it to uint32_t gives us 0x67bdfff0.

Well, this is odd. I wouldn't expect casting would produce such result.

In D8250#172348, @br wrote:

here is another one possible solution

I like this solution better.

br updated this revision to Diff 21651.Oct 24 2016, 1:04 PM
br updated this object.

use instr_t for instruction storage.

rpaulo accepted this revision.Oct 24 2016, 3:05 PM
rpaulo edited edge metadata.
rpaulo added inline comments.
lib/libproc/proc_bkpt.c
71 ↗(On Diff #21651)

Maybe add a comment here explaining why this works for x86.

This revision is now accepted and ready to land.Oct 24 2016, 3:05 PM
br updated this revision to Diff 21701.Oct 26 2016, 2:11 PM
br edited edge metadata.

add comment

This revision now requires review to proceed.Oct 26 2016, 2:11 PM
This revision was automatically updated to reflect the committed changes.