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] Process record and replay, 5/10


Hi teawater,

Sorry for the big delay in my response.

El vie, 14-11-2008 a las 16:36 +0800, teawater escribiÃ:
> On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann
> <bauerman@br.ibm.com> wrote:
> > Syscalls have different numbers across different architectures in Linux,
> > so this file should be named i386-linux-record.c.
> 
> This number is same with i386 number. It's friendly to other arch.
> 
> Let me do a introduce of it.
> When a record get a system call. It will get the the system number
> with itself and convert it to the number that you found in
> linux-record.c. I think it can use a table or something like it to
> make covert speed up.
> There is not some limit of this number. So I make it same with I386.

So are you saying that record_linux_system_call takes a syscall number
which is internal to GDB and doesn't necessarily correspond to the
syscall numbers used in the target?

Right now there's only the i386 implementation of record, so the
internal implementation is equivalent to it (and indeed,
i386_linux_intx80_sysenter_record takes the syscall number from the
register and passes it to record_linux_system_call).

If that is the case, then I'm ok. But a comment in
record_linux_system_call explaining this intended use would help someone
wanting to add record support to a new architecture.

> > Do you know if what you need to record for a syscall in one architecture
> > is the same as what you need to record in the others? If so, it wouldn't
> > be hard to make this file general for Linux in all architectures, and
> > just get the syscall number mapping from the XML in the catch syscall
> > feature (here are we talking about it again... :-) ). Otherwise, you'll
> > have to rename the file, and also you can't directly call
> > record_linux_system_call directly from i386-linux-tdep.c like you do
> > now. You'd have to add a gdbarch method and reach this code through
> > that.
> 
> I think most of system call in each arch are same. Except the size of
> variables is not same. So I let arch set the size to argv "tdep" of
> record_linux_system_call.
> 
> And if some system call of a arch is not same with others. It can deal
> with it in code of itself. For example, If i386 have a special system
> call that not same with other arch. It can deal with it in function
> "i386_linux_intx80_sysenter_record".

I like this idea. I don't have any authority or experience to make
recommendations about this, but I'd guess that like you say, most
syscalls across architectures in Linux would be similar and mostly
differ by sizes of types and structures. If exceptions to this rule can
be dealt with separately, than most of the laborious syscall-recording
work can be reused in record_linux_system_call. Sounds great, thanks for
the explanation.

If you could mention this intention of reusing this function for other
architectures, that would tip someone wanting to port record to another
architecture, IMHO.

> Put it to xml file it's been talk in
> "http://sourceware.org/ml/gdb-patches/2008-11/msg00171.html";.
> What about do it later?

Yes, it makes sense to me.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


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