* Re: [design change] record-replay linux ABI level [not found] <CAK1A=4xtgYd8hQEwHxjLQiv4eqhCu0cSRDmmbFJvBDJwDxUM+Q__46748.0269181125$1336555010$gmane$org@mail.gmail.com> @ 2012-05-09 20:39 ` Tom Tromey 2012-05-10 8:49 ` oza Pawandeep [not found] ` <CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com> 0 siblings, 2 replies; 16+ messages in thread From: Tom Tromey @ 2012-05-09 20:39 UTC (permalink / raw) To: oza Pawandeep; +Cc: gdb, gdb-patches >>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: oza> currently linux-record.h is having defination of oza> enum gdb_syscall {...} which seems generic one, but infact it only oza> addresses i386 arch. Based on reading the header, it seems to me that the idea is that this enum is intended to be generic, and that each target must provide its own mapping from the local syscalls to these. oza> I am thinking of moving all the definition to i386 specific files oza> (assuming there is no generic way to address all the systemcalls on oza> all arch). It seems to me that most syscalls could perhaps be shared, but maybe some architectures will require additions to the enum. I'm not sure, though. Could you say in more detail what problem you ran into? Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-09 20:39 ` [design change] record-replay linux ABI level Tom Tromey @ 2012-05-10 8:49 ` oza Pawandeep [not found] ` <CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com> 1 sibling, 0 replies; 16+ messages in thread From: oza Pawandeep @ 2012-05-10 8:49 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb, gdb-patches Tom, The definition of system call record maps fine to x86. but arm syscall numbers are different. [partially] for e.g. on x86 sycall number for sys_epoll_create = 254 while on ARM it is 250. the more we go down on defined system calls the more the numbers are differing on ARM and we loose one to one trivial mapping. Regards, Oza. On Thu, May 10, 2012 at 2:08 AM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: > > oza> currently linux-record.h is having defination of > oza> enum gdb_syscall {...} which seems generic one, but infact it only > oza> addresses i386 arch. > > Based on reading the header, it seems to me that the idea is that this > enum is intended to be generic, and that each target must provide its > own mapping from the local syscalls to these. > > oza> I am thinking of moving all the definition to i386 specific files > oza> (assuming there is no generic way to address all the systemcalls on > oza> all arch). > > It seems to me that most syscalls could perhaps be shared, but maybe > some architectures will require additions to the enum. > > I'm not sure, though. > > Could you say in more detail what problem you ran into? > > Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com>]
* Re: [design change] record-replay linux ABI level [not found] ` <CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com> @ 2012-05-10 13:39 ` Tom Tromey 2012-05-13 7:19 ` oza Pawandeep 0 siblings, 1 reply; 16+ messages in thread From: Tom Tromey @ 2012-05-10 13:39 UTC (permalink / raw) To: oza Pawandeep; +Cc: gdb, gdb-patches Oza> The definition of system call record maps fine to x86. but arm Oza> syscall numbers are different. [partially] for e.g. on x86 sycall Oza> number for sys_epoll_create = 254 while on ARM it is 250. the more Oza> we go down on defined system calls the more the numbers are Oza> differing on ARM and we loose one to one trivial mapping. My understanding of the current design is that the ARM code would see the syscall 250, and have a mapping to turn that into gdb_sys_epoll_create (== 254). This can be done bidirectionally with two lookup tables. I suppose this could still not work in some scenarios. One question is whether these occur in practice or are merely theoretical. I don't really care about this API either way. With a solid justification it is fine to change it. Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-10 13:39 ` Tom Tromey @ 2012-05-13 7:19 ` oza Pawandeep 2012-05-13 7:33 ` oza Pawandeep 0 siblings, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-05-13 7:19 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb, gdb-patches currently on i386 following is the function: static enum gdb_syscall i386_canonicalize_syscall (int syscall) { enum { i386_syscall_max = 499 }; if (syscall <= i386_syscall_max) return syscall; else return -1; } which is just straight mapping. If we use generic enum defination, we will end up adding some additional syscalls for ARM and arm_canonicalize_syscall(int syscall) end up having switch {case} and having one-to one mapping for some syscalls and rest syscalls would be shift by 'n' position. which looks clumsy to me. I am trying to see if there is more generic way which would take care of all archor move the defination to arch files. will try to see what best could be done. Regards, Oza. On Thu, May 10, 2012 at 7:09 PM, Tom Tromey <tromey@redhat.com> wrote: > Oza> The definition of system call record maps fine to x86. but arm > Oza> syscall numbers are different. [partially] for e.g. on x86 sycall > Oza> number for sys_epoll_create = 254 while on ARM it is 250. the more > Oza> we go down on defined system calls the more the numbers are > Oza> differing on ARM and we loose one to one trivial mapping. > > My understanding of the current design is that the ARM code would see > the syscall 250, and have a mapping to turn that into > gdb_sys_epoll_create (== 254). This can be done bidirectionally with > two lookup tables. > > I suppose this could still not work in some scenarios. One question is > whether these occur in practice or are merely theoretical. > > I don't really care about this API either way. > With a solid justification it is fine to change it. > > Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-13 7:19 ` oza Pawandeep @ 2012-05-13 7:33 ` oza Pawandeep 2012-05-13 9:47 ` oza Pawandeep 0 siblings, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-05-13 7:33 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb, gdb-patches what I would do is, I will go ahead with curernt defination of enum. and try to provide mapping. if there are practical conflicts then I would seek for alternatives. Regards, Oza. On Sun, May 13, 2012 at 12:49 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote: > currently on i386 following is the function: > > static enum gdb_syscall > i386_canonicalize_syscall (int syscall) > { > enum { i386_syscall_max = 499 }; > > if (syscall <= i386_syscall_max) > return syscall; > else > return -1; > } > > which is just straight mapping. > > If we use generic enum defination, we will end up adding some > additional syscalls for ARM and > > arm_canonicalize_syscall(int syscall) > end up having switch {case} and having one-to one mapping for some > syscalls and rest syscalls would be shift by 'n' position. > which looks clumsy to me. > > > I am trying to see if there is more generic way which would take care > of all archor move the defination to arch files. > will try to see what best could be done. > > Regards, > Oza. > > > > On Thu, May 10, 2012 at 7:09 PM, Tom Tromey <tromey@redhat.com> wrote: >> Oza> The definition of system call record maps fine to x86. but arm >> Oza> syscall numbers are different. [partially] for e.g. on x86 sycall >> Oza> number for sys_epoll_create = 254 while on ARM it is 250. the more >> Oza> we go down on defined system calls the more the numbers are >> Oza> differing on ARM and we loose one to one trivial mapping. >> >> My understanding of the current design is that the ARM code would see >> the syscall 250, and have a mapping to turn that into >> gdb_sys_epoll_create (== 254). This can be done bidirectionally with >> two lookup tables. >> >> I suppose this could still not work in some scenarios. One question is >> whether these occur in practice or are merely theoretical. >> >> I don't really care about this API either way. >> With a solid justification it is fine to change it. >> >> Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-13 7:33 ` oza Pawandeep @ 2012-05-13 9:47 ` oza Pawandeep 2012-05-14 14:57 ` Joel Brobecker 0 siblings, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-05-13 9:47 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb, gdb-patches following are the ARM syscalls. /* 270 */ CALL(sys_arm_fadvise64_64) CALL(sys_pciconfig_iobase) CALL(sys_pciconfig_read) CALL(sys_pciconfig_write) CALL(sys_mq_open) linux-record.h has a conflict at slot 271, 272 an so on.. sys_pciconfig_iobase is not defined at all. It is confusing where to define in the enum gdb_syscall table. current code looks like this... static enum gdb_syscall arm_canonicalize_syscall (int syscall) { enum { arm_sys_prlimit64 = 369 }; if (syscall <= arm_sys_prlimit64) { if (syscall <= gdb_sys_sched_getaffinity) return syscall; else if (syscall <= gdb_sys_fadvise64_64) { return (syscall + (unsigned int)2); } else { switch (syscall) { } } } else return -1; } It becomes clumsy as we start adding some more syscalls in the generic structure. (even If we are able to find slots). Regards, Oza. On Sun, May 13, 2012 at 1:03 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote: > what I would do is, I will go ahead with curernt defination of enum. > and try to provide mapping. > if there are practical conflicts then I would seek for alternatives. > > Regards, > Oza. > > On Sun, May 13, 2012 at 12:49 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote: >> currently on i386 following is the function: >> >> static enum gdb_syscall >> i386_canonicalize_syscall (int syscall) >> { >> enum { i386_syscall_max = 499 }; >> >> if (syscall <= i386_syscall_max) >> return syscall; >> else >> return -1; >> } >> >> which is just straight mapping. >> >> If we use generic enum defination, we will end up adding some >> additional syscalls for ARM and >> >> arm_canonicalize_syscall(int syscall) >> end up having switch {case} and having one-to one mapping for some >> syscalls and rest syscalls would be shift by 'n' position. >> which looks clumsy to me. >> >> >> I am trying to see if there is more generic way which would take care >> of all archor move the defination to arch files. >> will try to see what best could be done. >> >> Regards, >> Oza. >> >> >> >> On Thu, May 10, 2012 at 7:09 PM, Tom Tromey <tromey@redhat.com> wrote: >>> Oza> The definition of system call record maps fine to x86. but arm >>> Oza> syscall numbers are different. [partially] for e.g. on x86 sycall >>> Oza> number for sys_epoll_create = 254 while on ARM it is 250. the more >>> Oza> we go down on defined system calls the more the numbers are >>> Oza> differing on ARM and we loose one to one trivial mapping. >>> >>> My understanding of the current design is that the ARM code would see >>> the syscall 250, and have a mapping to turn that into >>> gdb_sys_epoll_create (== 254). This can be done bidirectionally with >>> two lookup tables. >>> >>> I suppose this could still not work in some scenarios. One question is >>> whether these occur in practice or are merely theoretical. >>> >>> I don't really care about this API either way. >>> With a solid justification it is fine to change it. >>> >>> Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-13 9:47 ` oza Pawandeep @ 2012-05-14 14:57 ` Joel Brobecker 2012-05-15 5:20 ` oza Pawandeep [not found] ` <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com> 0 siblings, 2 replies; 16+ messages in thread From: Joel Brobecker @ 2012-05-14 14:57 UTC (permalink / raw) To: oza Pawandeep; +Cc: Tom Tromey, gdb, gdb-patches > static enum gdb_syscall > arm_canonicalize_syscall (int syscall) > { > enum { arm_sys_prlimit64 = 369 }; > > if (syscall <= arm_sys_prlimit64) > { > if (syscall <= gdb_sys_sched_getaffinity) > return syscall; > else if (syscall <= gdb_sys_fadvise64_64) > { > return (syscall + (unsigned int)2); > } > else > { > switch (syscall) Why not define a table that defines the mapping for every syscall? We do that for registers -vs- register names, for instance, and that works very well. static enum gdb_syscall arm_syscal_map[] = { gdb_sys_restart_syscall, gdb_sys_exit, gdb_sys_fork, [...] gdb_sys_sched_getaffinity, gdb_sys_arm_trap16, [...] }; -- Joel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-14 14:57 ` Joel Brobecker @ 2012-05-15 5:20 ` oza Pawandeep 2012-05-15 5:34 ` Joel Brobecker [not found] ` <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com> 1 sibling, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-05-15 5:20 UTC (permalink / raw) To: Joel Brobecker; +Cc: Tom Tromey, gdb, gdb-patches I would have liked to think the same; but the way linux-record.h addresses all the architecture, the enum sycall, is defiend generically. what I think is define it in arch files, as syscalls are partially dependent on arch, though they follow posix standard. so each arch file would have their own map, compare to current generic map in linux-record.h Regards, Oza. On Mon, May 14, 2012 at 8:26 PM, Joel Brobecker <brobecker@adacore.com> wrote: >> static enum gdb_syscall >> arm_canonicalize_syscall (int syscall) >> { >> enum { arm_sys_prlimit64 = 369 }; >> >> if (syscall <= arm_sys_prlimit64) >> { >> if (syscall <= gdb_sys_sched_getaffinity) >> return syscall; >> else if (syscall <= gdb_sys_fadvise64_64) >> { >> return (syscall + (unsigned int)2); >> } >> else >> { >> switch (syscall) > > Why not define a table that defines the mapping for every syscall? > We do that for registers -vs- register names, for instance, and that > works very well. > > static enum gdb_syscall arm_syscal_map[] = > { > gdb_sys_restart_syscall, gdb_sys_exit, gdb_sys_fork, > [...] > gdb_sys_sched_getaffinity, gdb_sys_arm_trap16, > [...] > }; > > -- > Joel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-15 5:20 ` oza Pawandeep @ 2012-05-15 5:34 ` Joel Brobecker 0 siblings, 0 replies; 16+ messages in thread From: Joel Brobecker @ 2012-05-15 5:34 UTC (permalink / raw) To: oza Pawandeep; +Cc: Tom Tromey, gdb, gdb-patches > so each arch file would have their own map, compare to current generic > map in linux-record.h If I understand what you are saying correctly, I think that this is what I had in mind. NB: I should point out that I have little knowledge of the process- record code. Just trying to help out with possible solutions if we think the best option is to have one generic enum. -- Joel ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com>]
* Re: [design change] record-replay linux ABI level [not found] ` <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com> @ 2012-05-15 16:42 ` Tom Tromey 2012-05-16 10:48 ` oza Pawandeep 0 siblings, 1 reply; 16+ messages in thread From: Tom Tromey @ 2012-05-15 16:42 UTC (permalink / raw) To: oza Pawandeep; +Cc: Joel Brobecker, gdb, gdb-patches >>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: Oza> I would have liked to think the same; but the way linux-record.h Oza> addresses all the architecture, the enum sycall, is defiend Oza> generically. Oza> what I think is define it in arch files, as syscalls are partially Oza> dependent on arch, though they follow posix standard. Oza> so each arch file would have their own map, compare to current generic Oza> map in linux-record.h If it really makes things better, it is fine by me. What do you propose to do with record_linux_system_call? How about another approach? Keep the current mapping idea, but extract the mappings from syscalls/*.xml. That way we help out two features with a single data file. Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-15 16:42 ` Tom Tromey @ 2012-05-16 10:48 ` oza Pawandeep 2012-05-16 14:57 ` Tom Tromey 0 siblings, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-05-16 10:48 UTC (permalink / raw) To: Tom Tromey; +Cc: Joel Brobecker, gdb, gdb-patches Tom, a) yes; The record_linux_system_call is a problem because the conflicting number would conflict in {switch} {case} construct of the functions. b) I am not much familiar with xml generated C files, and where to change in gdb, but with that, will the record_linux_system_call be able to incorporate all conflicting syscall numbers in that case ? c) there is another way, which is align to current design. (it is not very very clean but manageable) define as follows enum gdb_syscall { /* i386 related syscalls */ /* ARM related syscalls */ /* MIPS related syscalls */ so on.. } if syscalls share the same number then it is one-to-one mapping. if at the same number, syscalls are different then add them under ARM number which would start just after i386. if there are common syscalls but different number then there would be shift by a number. then it has to be adjusted in function static enum gdb_arm_syscall arm_canonicalize_syscall (int syscall) { enum { arm_sys_prlimit64 = 369 }; if (syscall <= arm_sys_prlimit64) return syscall; else return -1; } Regards, Oza. On Tue, May 15, 2012 at 10:11 PM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: > > Oza> I would have liked to think the same; but the way linux-record.h > Oza> addresses all the architecture, the enum sycall, is defiend > Oza> generically. > > Oza> what I think is define it in arch files, as syscalls are partially > Oza> dependent on arch, though they follow posix standard. > > Oza> so each arch file would have their own map, compare to current generic > Oza> map in linux-record.h > > If it really makes things better, it is fine by me. > > What do you propose to do with record_linux_system_call? > > > How about another approach? Keep the current mapping idea, but extract > the mappings from syscalls/*.xml. That way we help out two features > with a single data file. > > Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-16 10:48 ` oza Pawandeep @ 2012-05-16 14:57 ` Tom Tromey 2012-06-05 9:16 ` oza Pawandeep 2012-06-05 9:19 ` oza Pawandeep 0 siblings, 2 replies; 16+ messages in thread From: Tom Tromey @ 2012-05-16 14:57 UTC (permalink / raw) To: oza Pawandeep; +Cc: Joel Brobecker, gdb, gdb-patches >>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: oza> b) I am not much familiar with xml generated C files, and where to oza> change in gdb, but with that, will the record_linux_system_call be oza> able to incorporate all conflicting syscall numbers in that case ? The idea is to extend the current approach. That is, have a single generic enum; then map the system-specific numbers to this enum. The difference is that the mappings would be generated from the XML files. oza> define as follows oza> enum gdb_syscall oza> { oza> /* i386 related syscalls */ oza> /* ARM related syscalls */ oza> /* MIPS related syscalls */ oza> so on.. oza> } Yeah, I don't like this much. Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-16 14:57 ` Tom Tromey @ 2012-06-05 9:16 ` oza Pawandeep 2012-06-06 18:17 ` Tom Tromey 2012-06-05 9:19 ` oza Pawandeep 1 sibling, 1 reply; 16+ messages in thread From: oza Pawandeep @ 2012-06-05 9:16 UTC (permalink / raw) To: Tom Tromey; +Cc: Joel Brobecker, gdb, gdb-patches I have gone through some of the xml stuffs already done. under gdb/syscalls/arch_linux.xml files exist. which is currently not used for record-purpose. there are 2 ways we could go ahead now: 1) use the above file for recording purpose too and define new arm-linux.xml for arm specific syscalls. 2) or we decide to keep only one combined xml files for record-replay future for all arch. PS: syscall code is almost done now, it supports 242 syscalls [till gdb_sys_sched_getaffinity = 242] (xml stuff is pending) Regards, Oza. On Wed, May 16, 2012 at 8:26 PM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: > > oza> b) I am not much familiar with xml generated C files, and where to > oza> change in gdb, but with that, will the record_linux_system_call be > oza> able to incorporate all conflicting syscall numbers in that case ? > > The idea is to extend the current approach. That is, have a single > generic enum; then map the system-specific numbers to this enum. The > difference is that the mappings would be generated from the XML files. > > oza> define as follows > oza> enum gdb_syscall > oza> { > oza> /* i386 related syscalls */ > oza> /* ARM related syscalls */ > oza> /* MIPS related syscalls */ > oza> so on.. > oza> } > > Yeah, I don't like this much. > > Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-06-05 9:16 ` oza Pawandeep @ 2012-06-06 18:17 ` Tom Tromey 0 siblings, 0 replies; 16+ messages in thread From: Tom Tromey @ 2012-06-06 18:17 UTC (permalink / raw) To: oza Pawandeep; +Cc: Joel Brobecker, gdb, gdb-patches >>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: Oza> 1) use the above file for recording purpose too and define new Oza> arm-linux.xml for arm specific syscalls. Oza> 2) or we decide to keep only one combined xml files for record-replay Oza> future for all arch. I think separate files is best. If there is substantial commonality, we can do inclusions, the way that is done in some features/*.xml files. E.g, from features/arm-with-m.xml: <!DOCTYPE target SYSTEM "gdb-target.dtd"> <target> <xi:include href="arm-m-profile.xml"/> </target> Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [design change] record-replay linux ABI level 2012-05-16 14:57 ` Tom Tromey 2012-06-05 9:16 ` oza Pawandeep @ 2012-06-05 9:19 ` oza Pawandeep 1 sibling, 0 replies; 16+ messages in thread From: oza Pawandeep @ 2012-06-05 9:19 UTC (permalink / raw) To: Tom Tromey; +Cc: Joel Brobecker, gdb, gdb-patches I have gone through some of the xml stuffs already done. under gdb/syscalls/arch_linux.xml files exist. which is currently not used for record-purpose. there are 2 ways we could go ahead now: 1) use the above file for recording purpose too and define new arm-linux.xml for arm specific syscalls. 2) or we decide to keep only one combined xml files for record-replay future for all arch. PS: syscall code is almost done now, it supports 242 syscalls [till gdb_sys_sched_getaffinity = 242] (xml stuff is pending, for which either approach 1) or 2) could be taken.) Regards, Oza. On Wed, May 16, 2012 at 8:26 PM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes: > > oza> b) I am not much familiar with xml generated C files, and where to > oza> change in gdb, but with that, will the record_linux_system_call be > oza> able to incorporate all conflicting syscall numbers in that case ? > > The idea is to extend the current approach. That is, have a single > generic enum; then map the system-specific numbers to this enum. The > difference is that the mappings would be generated from the XML files. > > oza> define as follows > oza> enum gdb_syscall > oza> { > oza> /* i386 related syscalls */ > oza> /* ARM related syscalls */ > oza> /* MIPS related syscalls */ > oza> so on.. > oza> } > > Yeah, I don't like this much. > > Tom ^ permalink raw reply [flat|nested] 16+ messages in thread
* [design change] record-replay linux ABI level @ 2012-05-09 9:16 oza Pawandeep 0 siblings, 0 replies; 16+ messages in thread From: oza Pawandeep @ 2012-05-09 9:16 UTC (permalink / raw) To: gdb, gdb-patches Hi all, currently linux-record.h is having defination of enum gdb_syscall {...} which seems generic one, but infact it only addresses i386 arch. the way the arm syscall number defined are different and mapping is different. I am thinking of moving all the definition to i386 specific files (assuming there is no generic way to address all the systemcalls on all arch). there might be similar instances which also like to be moved to i386 specific file (for e.g. struct linux_record_tdep { /* The size of the type that will be used in a system call. */ int size_pointer; int size__old_kernel_stat; int size_tms; - - - - - } please let me know any input for the same, as I am working on arm syscall recording part. Regards, Oza. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-06-06 18:17 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAK1A=4xtgYd8hQEwHxjLQiv4eqhCu0cSRDmmbFJvBDJwDxUM+Q__46748.0269181125$1336555010$gmane$org@mail.gmail.com> 2012-05-09 20:39 ` [design change] record-replay linux ABI level Tom Tromey 2012-05-10 8:49 ` oza Pawandeep [not found] ` <CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com> 2012-05-10 13:39 ` Tom Tromey 2012-05-13 7:19 ` oza Pawandeep 2012-05-13 7:33 ` oza Pawandeep 2012-05-13 9:47 ` oza Pawandeep 2012-05-14 14:57 ` Joel Brobecker 2012-05-15 5:20 ` oza Pawandeep 2012-05-15 5:34 ` Joel Brobecker [not found] ` <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com> 2012-05-15 16:42 ` Tom Tromey 2012-05-16 10:48 ` oza Pawandeep 2012-05-16 14:57 ` Tom Tromey 2012-06-05 9:16 ` oza Pawandeep 2012-06-06 18:17 ` Tom Tromey 2012-06-05 9:19 ` oza Pawandeep 2012-05-09 9:16 oza Pawandeep
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).