This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFA 3/5] New port: CR16: gdb port
> I think we should hold the gdb bits until the gdbserver parts are settled,
> as we're discussing core register numbering issues.
> What did you think of my suggestions/comments to the gdb patch?
Yes, I do want to address those as well :)
> How about exporting a function that hides these opcodes details?
> I don't even pretend to understand what the code is trying to do,
> and it'd be an opportunity to comment it in the function description.
> /* Take BUF, do something with it, and write length
> to LENGTH. Blah, blah. */
> cr16_do_something (buf, *length, ...);
I think this can be done and it will make this code look cleaner.
An exported function in bfd would make my code look like this,
...
target_read_memory (pc, buf, 6);
cr16_get_insn_length (buf, *length, ...);
next_pc = pc + length;
...
> > + "r0r1_orig",
> This too looks like a ptrace detail escaping all the
> way to the user, similar to the gdbserver issues.
> Any reason not to split those up? I think it'd be nicer.
This is a kernel scratch register and it part of PT_REGS.
Would be OK to leave it as is as it may help in debugging?
Thanks,
Kaushik