This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]