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

Why does GDB default to using compressed breakpoint instructions for s/w BPs? #106

Closed
TM1234 opened this Issue Sep 27, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@TM1234
Copy link

TM1234 commented Sep 27, 2017

As far as I can see the RISC-V port of gdb defaults to using compressed breakpoint instructions for software breakpoints. This means that if the target does not support the C extension then you need to explicitly tell gdb otherwise an illegal instruction fault will happen when an attempt is made to executed the invalid (in a non C architecture context) instruction:

set riscv use_compressed_breakpoints no

This seems unnecessary complication in the implementation and hassle for the end user - why not simply use non compressed BP instructions which are supported by all targets whether C or not?

Is there some reason that compressed BP instructions are preferred by default?

@ilg-ul

This comment has been minimized.

Copy link

ilg-ul commented Sep 27, 2017

isn't gdb aware of the architecture details?

@TM1234

This comment has been minimized.

Copy link
Author

TM1234 commented Sep 27, 2017

I think it should be from misa and maybe other csrs but at the moment to debug our specific RV32IM I have to do this otherwise gdb will assume a 64 bit target and ability to use compressed BP instructions:

set arch riscv:rv32
set riscv use_compressed_breakpoints no
@timsifive

This comment has been minimized.

Copy link
Contributor

timsifive commented Sep 27, 2017

gdb attempts to read MISA, and if C is set it will use compressed breakpoints: https://github.com/riscv/riscv-binutils-gdb/blob/riscv-binutils-2.29/gdb/riscv-tdep.c#L231

In older versions of the code it would be unable to read MISA if it was at the old location (it moved in some priv spec update). 697d5b8 fixed that issue.

@TM1234

This comment has been minimized.

Copy link
Author

TM1234 commented Sep 27, 2017

But why bother trying to use compressed BP instructions when uncompressed BP instructions are universally compatible?
Seems like unnecessary complication for the implementation and the end user to use compressed BP instructions?

@timsifive

This comment has been minimized.

Copy link
Contributor

timsifive commented Sep 27, 2017

The software breakpoint instruction can be no longer than the instruction it is replacing, in case the program contains a jump to the instruction right after it. Rather than figuring out the size of the instruction, it's much simpler just to use the smallest supported breakpoint instruction.

@TM1234

This comment has been minimized.

Copy link
Author

TM1234 commented Sep 27, 2017

The software breakpoint instruction can be no longer than the instruction it is replacing, in case the program contains a jump to the instruction right after it. Rather than figuring out the size of the instruction, it's much simpler just to use the smallest supported breakpoint instruction.

Thanks Tim - that explains matters alright.

gdb attempts to read MISA, and if C is set it will use compressed breakpoints: https://github.com/riscv/riscv-binutils-gdb/blob/riscv-binutils-2.29/gdb/riscv-tdep.c#L231

In older versions of the code it would be unable to read MISA if it was at the old location (it moved in some priv spec update). 697d5b8 fixed that issue.

So a build of gdb with that mod no longer needs:

set riscv use_compressed_breakpoints no

regardless of the draft privilege spec that the target adheres to (1.9, 1.9.1 or 1.10)?

@TM1234

This comment has been minimized.

Copy link
Author

TM1234 commented Sep 27, 2017

So a build of gdb with that mod no longer needs:

set riscv use_compressed_breakpoints no

I just tried it with an RV32IM adhering to the 1.9 priv spec and that seems to be the case - i.e. it does the right thing (uses non compressed BP instruction) even when set riscv use_compressed_breakpoints no) is NOT specified.

Unfortunately set arch riscv:rv32 is still needed - shouldn't it be able to figure out the XLEN from misa or some other CSR to obviate the need for this?

@timsifive

This comment has been minimized.

Copy link
Contributor

timsifive commented Sep 27, 2017

Unfortunately set arch riscv:rv32 is still needed - shouldn't it be able to figure out the XLEN from misa or some other CSR to obviate the need for this?

Yes, but unfortunately it's not so easily implemented. This is #54

@TM1234

This comment has been minimized.

Copy link
Author

TM1234 commented Nov 2, 2017

Since the rationale for using compressed bps where supported was explained above I'm closing this issue now.

@TM1234 TM1234 closed this Nov 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment