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 2/4] 'catch syscall' feature -- Architecture-dependent part


Hi Tom,

On Tue, 2008-11-04 at 09:15 -0700, Tom Tromey wrote:
> >>>>> "Sérgio" == Sérgio Durigan Júnior <sergiodj@linux.vnet.ibm.com> writes:
> 
> Sérgio> 	* i386-linux-tdep.c: Define the syscall's XML struct to hold
> Sérgio> 	information about syscalls.
> Sérgio> 	(init_sysinfo): New.
> 
> There is some code duplication between this and ppc-linux-tdep.c.
> It seems to me that much of the Linux code will be shared by all
> ports.  So, I think the duplicated stuff should go in linux-nat.c.

Thank you so much for this comment! I was aware of this replication, but
I still wasn't able to figure out a way to solve this. Now it looks so
obvious! I'll put the common functions in linux-nat.c :-).

> Sérgio> 	(i386_linux_get_syscall_number): New.
> Sérgio> 	(i386_linux_syscall_name_from_number): New.
> Sérgio> 	(i386_linux_syscall_number_from_name): New.
> Sérgio> 	(i386_linux_get_syscalls_names): New.
> 
> In the current patch, these could all be static.  Aside from
> i386_linux_get_syscall_number, perhaps they ought to be shared in
> linux-nat.c though.  The same applies for the equivalent PPC functions.

Right, I'll do it for both. But I have a question. Depending on the
architecture, I must pick the correct XML file to open and parse. That's
why I've put these functions in separate files. So, do you have a clue
on how to solve this?

> Sérgio> +/* Return the current system call's number present in the
> Sérgio> +   r0 register.  When the function fails, it returns -1.  */
> Sérgio> +LONGEST
> Sérgio> +ppc_linux_get_syscall_number (struct gdbarch *gdbarch,
> Sérgio> +                              ptid_t ptid)
> Sérgio> +{
> [...]
> Sérgio> +  buf = (gdb_byte *) xmalloc (tdep->wordsize * sizeof (gdb_byte));
> 
> I suspect you need a cleanup here, rather than an explicit xfree.  I
> am not sure.  If regcache_cooked_read can call error, then you need
> one.

Good point. I'll do that. Thanks.

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil


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