Skip to content

X86_64: silence some truncation warnings #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

compnerd
Copy link
Owner

There are a number of places where we truncate to a 32-bit value from a 64-bit value as we may running a 32-bit binary on 64-bits. This silences some of the warnings by explicitly truncating the integers rather than implicitly performing the operation.

Copy link
Contributor

@fischman-bcny fischman-bcny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IWBN to ack in comments that these are truncating operations, with the explanation for why this is ok.

@compnerd
Copy link
Owner Author

I like that idea - I wonder if they will get a bit too repetitive, but I can see if I can add them appropriately. Would be nice to get a second pair of eyes to verify that these are indeed safe (which I believe them to be).

There are a number of places where we truncate to a 32-bit value from a
64-bit value as we may running a 32-bit binary on 64-bits. This silences
some of the warnings by explicitly truncating the integers rather than
implicitly performing the operation.
@compnerd compnerd force-pushed the compnerd/truncation branch from 938f1d9 to d628096 Compare July 14, 2023 03:27
@compnerd compnerd requested a review from fischman-bcny July 14, 2023 03:27
gp.es = regs[21];
gp.fs = regs[22];
gp.gs = regs[23];
// Truncate the value to 32-bit as these are 32-bit registers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm a bit confused about the point of CPUState64 being a union. Why not simply
memcpy(gp.regs, regs, sizeof(gp.regs));
and avoid the need to remember which of these need to be truncated, etc?

@@ -594,7 +595,7 @@ struct CPUState {
}
inline void setPC(uint64_t pc) {
if (is32)
state32.setPC(pc);
state32.setPC(static_cast<uint32_t>(pc));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in slack, IMO better to have a helper like

// When debugging a 32-bit inferior on a 64-bit platform registers etc frequently need truncation to 32-bits with an assumption that the high bits are zero. This helper does the cast and asserts no information is lost in the process.
static inline truncate64To32Losslessly(uint64_t data) {
  DS2ASSERT(data >> 32 == 0 && "64-bit value being truncated to 32-bits has non-zero high word");
  return static_cast<uint32_t>(data);
}

@@ -193,7 +193,7 @@ int HardwareBreakpointManager::hit(Target::Thread *thread, Site &site) {
if (debugRegs[kStatusRegIdx] & (1ull << i)) {
DS2ASSERT(_locations[i] != 0);
site = _sites.find(_locations[i])->second;
regIdx = i;
regIdx = static_cast<int>(i);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

simpler to s/size_t/int/ at l.192?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants