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: [RFC] New GDB Port CR16


Hi,
Thanks for all your comments till date. I have attached the diffs separately,
though I do plan to do it in different threads soon. I am still trying to clear 
up couple of issues before that. If anybody could give me suggestions on these,
it would be very much appreciated.

1. The elf and uclinux binaries seem to get built after adding their triplets
in configure.tgt, however I am having a hard time getting the cr16-uclinux-gdb
to work with the hardware. On debugging, I found that this binary transmitted 
data during a call to update_address_spaces function called from 
remote_start_remote in remote.c
The additional packet transmitted is as below,
{
Sending packet: $qXfer:auxv:read::0,1000#6b...Packet received: l\000\000\000\000\000\000\000\000
}
After this, the gdbserver communication would either hang, or kernel would crash
and the host would get a timeout. On additional debugging, this packet seemed
to get generated from the call to gdbarch_has_shared_address_space().
Previously, the whole setup has been tested with host side gdb being built
independently with different breakpoint and register set. This method of using
linux-tdep.c seems to be inline with other ports, but maybe I am missing 
something, any pointers?

2. The cr16 target has -fPIC support and the data section is at an offset
to the end of text section. However, the symbol file created only shows me one
segment(0). So, the global data access takes place with offsets calculated with
respect to the start of .text section. This causes all reads to global data
to be incorrect. The attached patch which is a hack to get around 
this:"gdb_core_fpic_suspect.diff" Is there an elegant way to achieve this?

Mike, you had given the below feedback,
http://sourceware.org/ml/gdb-patches/2012-08/msg00819.html
> +int
>  match_opcode (void)
> this new local prototype makes no sense.  just delete it.

When I remove these prototypes, it gives me a warning as follows,
warning: no previous prototype for match_opcode
Our build fails as it treats warnings as error. We can get around that by
using "--disable-werror" I guess. But would this hunk be acceptable as is?

The attached patched are:
cr16_config_toplevel_alpha.diff -> top level changes to be submitted to gcc-patches
cr16_config_tgt_alpha.diff -> configure.tgt changes
cr16_bfd.diff -> bfd level changes to be submitted to binutils
cr16_gdb_alpha.diff -> cr16-tdep and cr16-linux-tdep related patch
gdb_core_fpic_suspect.diff -> The patch in question for -fPIC implementation.


Thanks & Best Regards,
Kaushik Phatak

Attachment: cr16_gdb_alpha.diff
Description: cr16_gdb_alpha.diff

Attachment: gdb_core_fpic_suspect.diff
Description: gdb_core_fpic_suspect.diff

Attachment: cr16_bfd.diff
Description: cr16_bfd.diff

Attachment: cr16_config_tgt_alpha.diff
Description: cr16_config_tgt_alpha.diff

Attachment: cr16_config_toplevel_alpha.diff
Description: cr16_config_toplevel_alpha.diff


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