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: [patch] gdbarch_syscall_pc_increment


On 12-12-12 10:30 AM, Yao Qi wrote:
Hi,
I don't understand why do you add a gdbarch hook, but use it only in a
target-specific part?  The goal of gdbarch hooks is about hiding the
difference of ports and giving a common interface to the common part of
GDB.  If your issue is arm specific, we don't need this new gdbarch hook
at all.


This is generic for a given OS that happens to increment instruction pointer to allow user code to e.g. set errno.

I provided only arm implementation, but other target cpus would need the same if they implement software single stepping.

Increment is cpu specific for a given architecture.



If I understand your problem correctly, you have to define your own function 'arm_neutrino_syscall_next_pc' in your file arm-neutrino-tdep.c, and install it on function pointer 'syscall_next_pc' (in 'struct gdbarch_tdep' in arm-tdep.h) in 'arm_neutrino_init_abi'. Please have a look on how 'syscall_next_pc' is set in arm-linux-tdep.c. Then you can compute the pc for your own os in 'arm_neutrino_syscall_next_pc'. Hope it helps.


No, the destination is not a single address as we do not know the outcome of the syscall. It may come back with the instruction pointer of the next instruction after 'svc' but also 4 bytes later (4 bytes in our case, some other kernel may implement it differently).


Hope this clarifies,


Aleksandar


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