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] |
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] |