Page MenuHomeFreeBSD

fix libproc for big-endian systems
ClosedPublic

Authored by br on Oct 14 2016, 2:24 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 29, 8:18 AM
Unknown Object (File)
Mar 25 2024, 5:58 AM
Unknown Object (File)
Mar 21 2024, 3:47 AM
Unknown Object (File)
Mar 21 2024, 3:47 AM
Unknown Object (File)
Mar 21 2024, 3:47 AM
Unknown Object (File)
Mar 21 2024, 3:47 AM
Unknown Object (File)
Feb 15 2024, 4:48 PM
Unknown Object (File)
Feb 2 2024, 9:28 AM
Subscribers
None

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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.

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

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?

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?

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 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 object.

use instr_t for instruction storage.

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 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.