Skip to content
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

Prevent crash on ARM32 #1412

Closed
wants to merge 3 commits into from

Conversation

kant2002
Copy link
Contributor

This change has 2 parts, one which is JIT part and likely require submission to runtime.
I keep that change here to give full scope of changes. Will extract if everything would be fine.
JIT for ARM now start numering floating point registers starting from 256

Second part is DWARF generation
In order to produce DWARF I made following changes

  • Account for register numbers more then 31, by use DW_OP_bregx and DW_OP_regx for large regnum
  • Combine VLT_FPSTK and VLT_STK handling.

See #1388

This change has 2 parts, one which is JIT part and likely require submission to runtime.
I keep that change here to give full scope of changes. Will extract if everything would be fine.
JIT for ARM now start numering floating point registers starting from 256

Second part is DWARF generation
In order to produce DWARF I made following changes
- Account for register numbers more then 31, by use DW_OP_bregx and DW_OP_regx for large regnum
- Combine VLT_FPSTK and VLT_STK handling.

See dotnet#1388
@@ -331,6 +367,7 @@ static void EmitVarLocation(MCObjectStreamer *Streamer,
IsByRef = true;
case ICorDebugInfo::VLT_STK2:
IsStk2 = true;
case ICorDebugInfo::VLT_FPSTK:
Copy link
Member

Choose a reason for hiding this comment

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

Did you actually hit this case? I would not expect it to be hit on. Floating point stack is a legacy 32-bit x86 that are not using anymore even on 32-bit x86.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is hit. I was tired of seeing assertion. This change was fishy to me too. But I do not know where to start looking. With that hint, I try to pin-point what can cause code to hit that location.

Copy link
Member

Choose a reason for hiding this comment

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

I have looked around. VLT_FPSTK is actually used for regular local variables that do not live on floating point stack. It does not look right; but it may done that way for some legacy reasons. So your change is ok.

Streamer->EmitIntValue(DwarfRegNum + dwarf::DW_OP_breg0, 1);
}
else {
Streamer->EmitIntValue(dwarf::DW_OP_bregx, 1);
Copy link
Member

Choose a reason for hiding this comment

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

According to the dwarf manual: "The DW_OP_bregx operation has two operands: a register which is specified by an unsigned LEB128 number, followed by a signed LEB128 offset.". It would be nice to emit the offset as part of this function instead of emitting it in the calling code.

src/coreclr/jit/unwind.cpp Outdated Show resolved Hide resolved
#else
regNum = REG_NEXT(regNum),
#endif
regBit <<= 1)
Copy link
Member

Choose a reason for hiding this comment

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

Does this need to shift the bit by 2 for floats as well?

@kant2002
Copy link
Contributor Author

@jkotas If you don't have any other suggestions, can I split this PR on two parts? One for runtime, second for this repo.

@jkotas
Copy link
Member

jkotas commented Aug 15, 2021

I do not have any other comments.

can I split this PR on two parts? One for runtime, second for this repo.

Yes, it would be nice. Thank you!

@kant2002
Copy link
Contributor Author

Superseeded by #1413 and dotnet/runtime#57443

@kant2002 kant2002 closed this Aug 15, 2021
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