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


Hi Pedro,
Thanks for another round of detailed review.

>> Hmm.  Just to be clear, isn't exposing r0_orig to gDB necessary for
>> syscall restarting, like orig_eax/orig_rax on x86/x86_64, orig_r3 on ppc,
>> orig_r2 on s390, etc.?  See e.g., i386_linux_write_pc, amd64_linux_write_pc,
>> ppc_linux_write_pc, s390_write_pc.

The original PTRACE implementation disallowed write to orig_r0and1, however read
was permitted. We can implement this as suggested above, so user may write a -1 to 
this register to prevent a SIGSEGV or SIGILL similar to amd64_linux_write_pc.
The signal handler checks for "regs->orig_r0and1 >= 0" before performing a -ERESTARTSYS
I will add this register to linux-tdep in gdb as well as the gdbserver port, ok?

>> Are these always present in all versions of CR16 silicon?  IOW, are
>> we safe with adding them to the core register set (*)?  
>> (*) which registers are those btw?  I'm not that familiar with CR16.  :-)
The following 5 registers have been added to this patch, which are debug registers,
"dbs","dcrl","dsr","car0","car1"
These registers are not part of every silicon and can be an optional feature.
However, the current simulator port seems to support these by default.

>> you should really split them to a separate target description feature.
Is there any other port i can refer for this?  

I will run through my code again and work on the other formatting related comments
provided.

Thanks,
Kaushik



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