Issue 311350043: Add test linux.sigaction0, testing sigaction syscall without signals. (Closed)
|
Created:
7 years, 4 months ago by Edmund.Grimley.Evans Modified:
7 years, 4 months ago CC:
dynamorio-devs_googlegroups.com Visibility:
Public. |
DescriptionCommit log for first patchset:
---------------
Add test linux.sigaction0, testing sigaction syscall without signals.
The "sigaction" system call is fairly complex, even in the absence of
signals, and should be emulated accurately by DynamoRIO. The test
is disabled as it does not yet pass.
---------------
Patch Set 1 #
Total comments: 5
Patch Set 2 : print #
Total comments: 36
Patch Set 3 : Renaming #Patch Set 4 : Rename files #
Total comments: 4
Patch Set 5 : Committed #
MessagesTotal messages: 19
Sign in to reply to this message.
Why "linux.sigaction0" instead of just "linux.sigaction"?
Sign in to reply to this message.
need use print instead of printf. https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.c File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.... suite/tests/linux/sigaction0.c:360: printf("all done\n"); we should include tools.h and use print() instead.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.c File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.... suite/tests/linux/sigaction0.c:360: printf("all done\n"); On 2016/12/02 16:28:46, zhaoqin wrote: > we should include tools.h and use print() instead. Why's that? Advantage of using printf: it's a stand-alone program which you can easily compile and run from the command line, which is what you probably want to do if you ever modify it, in order to check its behaviour on several different systems.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.c File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.... suite/tests/linux/sigaction0.c:360: printf("all done\n"); On 2016/12/02 16:56:39, Edmund.Grimley.Evans wrote: > On 2016/12/02 16:28:46, zhaoqin wrote: > > we should include tools.h and use print() instead. > > Why's that? > > Advantage of using printf: it's a stand-alone program which you can easily > compile and run from the command line, which is what you probably want to do if > you ever modify it, in order to check its behaviour on several different > systems. Please read https://github.com/DynamoRIO/dynamorio/wiki/Test-Suite "Adding New Tests". Using printf is a source of test flakiness, both from output ordering and from failure to flush on Windows (yes even stderr on Windows has flushing problems).
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.c File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.... suite/tests/linux/sigaction0.c:360: printf("all done\n"); > Using printf is a source of test flakiness, both from output ordering and from > failure to flush on Windows (yes even stderr on Windows has flushing problems). Not applicable to this case where there is only a single thread, outputting only to stdout, just before exiting. And the test in Linux-specific. But I'll change it anyway (and change it back temporarily if I ever have to maintain it).
Sign in to reply to this message.
Commit log for latest patchset: --------------- Add test linux.sigaction0, testing sigaction syscall without signals. The "sigaction" system call is fairly complex, even in the absence of signals, and should be emulated accurately by DynamoRIO. The test is disabled as it does not yet pass. Review-URL: https://codereview.appspot.com/311350043 ---------------
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.c File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/1/suite/tests/linux/sigaction0.... suite/tests/linux/sigaction0.c:360: printf("all done\n"); On 2016/12/02 17:16:54, Edmund.Grimley.Evans wrote: > > Using printf is a source of test flakiness, both from output ordering and from > > failure to flush on Windows (yes even stderr on Windows has flushing > problems). > > Not applicable to this case where there is only a single thread, outputting only > to stdout, just before exiting. And the test in Linux-specific. But I'll change > it anyway (and change it back temporarily if I ever have to maintain it). The output ordering issue is often between a client and the app and so happens in single-threaded tests. Best to match the other tests for consistency.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ why hard coded value instead of something like sizeof(sigset_t). https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:67: #define MARGIN 8 do you mean padding between the array element? https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:101: if (!(1 <= signum && signum <= SIGMAX) || hmm, 1 <= signum. the code style suggest: GOOD: if (i == 0) BAD: if (0 == i) maybe signum >= 1 is not too bad. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:167: size_t n = sizeof(test_rw_sys); nits, use named macro https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:241: size_t n = sizeof(sim1); would a named macro with more meaningful name be better? https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:267: sigsetsize, prot1, prot2); why did not we do the same thing for sim1/2 as we did for test_prot_mem1/2, i.e., separate mmap and change protection? some comment would be helpful here. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:321: mprotect_nofail(test_edge_base + test_edge_size, test_edge_size, prot2); should these two protection be in the init_test_edge? Also, do you think if it would be better if middle (test_edge_base + test_edge_size) as a global var as test_edge_base?
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ On 2016/12/05 16:50:39, zhaoqin wrote: > why hard coded value instead of something like sizeof(sigset_t). I can't get the size of kernel_sigset_t from the C library's header files. Either I hardcode SIGSETSIZE, or I hardcode the definition of kernel_sigset_t. This way round is neater, I think. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:67: #define MARGIN 8 On 2016/12/05 16:50:38, zhaoqin wrote: > do you mean padding between the array element? It's a margin used by the test program to detect writes outside the area that should be written to. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:101: if (!(1 <= signum && signum <= SIGMAX) || On 2016/12/05 16:50:38, zhaoqin wrote: > hmm, 1 <= signum. > the code style suggest: > GOOD: if (i == 0) > BAD: if (0 == i) > maybe signum >= 1 is not too bad. I don't really mind, but I tend to write (a <= x && x <= b) when checking x is in a range because it's slightly more similar to the standard mathematical notation: a <= x <= b. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:167: size_t n = sizeof(test_rw_sys); On 2016/12/05 16:50:38, zhaoqin wrote: > nits, use named macro Why is a named macro better than a named variable? https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:241: size_t n = sizeof(sim1); On 2016/12/05 16:50:38, zhaoqin wrote: > would a named macro with more meaningful name be better? I'd prefer a named variable. Presumably it's the name you don't like rather than the fact it's a variable? I tend to use macros only when there is a good reason for not using a variable. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:267: sigsetsize, prot1, prot2); On 2016/12/05 16:50:38, zhaoqin wrote: > why did not we do the same thing for sim1/2 as we did for test_prot_mem1/2, > i.e., separate mmap and change protection? > some comment would be helpful here. I'll try to write a comment. The simulated sigaction cannot detect memory protection. (Well, it could, perhaps, using read/write but that would make the test much more fragile as we'd have to depend on read/write being implemented correctly.) https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:321: mprotect_nofail(test_edge_base + test_edge_size, test_edge_size, prot2); On 2016/12/05 16:50:38, zhaoqin wrote: > should these two protection be in the init_test_edge? We test with several different memory protections. > Also, do you think if it would be better if middle (test_edge_base + > test_edge_size) as a global var as test_edge_base? It could be another value returned from init_test_edge...
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:33: /* Test sigaction without signals. */ Is that what the "0" means? Better to call it sigaction_nosignals.c or something. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:39, zhaoqin wrote: > > why hard coded value instead of something like sizeof(sigset_t). > > I can't get the size of kernel_sigset_t from the C library's header files. > Either I hardcode SIGSETSIZE, or I hardcode the definition of kernel_sigset_t. > This way round is neater, I think. Why does this test need to use the raw kernel interface rather than the C library interface?
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:33: /* Test sigaction without signals. */ On 2016/12/05 17:41:39, bruening wrote: > Is that what the "0" means? Better to call it sigaction_nosignals.c or > something. Yes, I have a bad habit of adding a digit to the end of a symbol to make a new, somehow related one... https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ On 2016/12/05 17:41:39, bruening wrote: > Why does this test need to use the raw kernel interface rather than the C > library interface? Because I'm testing DR's implementation of the system call which can't be done through a C library function whose implementation is unknown... I would guess that it's not possible to get an EFAULT from calling the C library function because the C library function gives the kernel a pointer to its own stack frame.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ On 2016/12/05 19:42:50, Edmund.Grimley.Evans wrote: > On 2016/12/05 17:41:39, bruening wrote: > > Why does this test need to use the raw kernel interface rather than the C > > library interface? > > Because I'm testing DR's implementation of the system call which can't be done > through a C library function whose implementation is unknown... > > I would guess that it's not possible to get an EFAULT from calling the C library > function because the C library function gives the kernel a pointer to its own > stack frame. The interface is *nearly* identical, but yes, the libc wrapper will crash on a bogus pointer. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:59: struct kernel_sigaction { style violation: types end in _t https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:59: struct kernel_sigaction { Some consideration should be spent on sharing types with the core which has these exact definitions: at least a comment on the duplication.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:49: #define SIGSETSIZE 8 /* size of sigset mask */ On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:39, zhaoqin wrote: > > why hard coded value instead of something like sizeof(sigset_t). > > I can't get the size of kernel_sigset_t from the C library's header files. > Either I hardcode SIGSETSIZE, or I hardcode the definition of kernel_sigset_t. > This way round is neater, I think. ok, reading from http://man7.org/linux/man-pages/man2/rt_sigaction.2.html I thought SIGSETSIZE is sizeof(sigset_t). Consequently, a new system call, rt_sigaction(), was added to support an enlarged sigset_t type. The new system call takes a fourth argument, size_t sigsetsize, which specifies the size in bytes of the signal sets in act.sa_mask and oldact.sa_mask. This argument is currently required to have the value sizeof(sigset_t) (or the error EINVAL results). https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:67: #define MARGIN 8 On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > do you mean padding between the array element? > > It's a margin used by the test program to detect writes outside the area that > should be written to. better to add that comment. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:101: if (!(1 <= signum && signum <= SIGMAX) || On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > hmm, 1 <= signum. > > the code style suggest: > > GOOD: if (i == 0) > > BAD: if (0 == i) > > maybe signum >= 1 is not too bad. > > I don't really mind, but I tend to write (a <= x && x <= b) when checking x is > in a range because it's slightly more similar to the standard mathematical > notation: a <= x <= b. I am ok with either, but consistency with code style would be preferred. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:167: size_t n = sizeof(test_rw_sys); On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > nits, use named macro > > Why is a named macro better than a named variable? named variable would be good. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:241: size_t n = sizeof(sim1); On 2016/12/05 17:38:28, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > would a named macro with more meaningful name be better? > > I'd prefer a named variable. Presumably it's the name you don't like rather than > the fact it's a variable? > > I tend to use macros only when there is a good reason for not using a variable. in C++, I would use const, so my immediate reaction in C is to use macro replace const. name variable would be good. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:267: sigsetsize, prot1, prot2); On 2016/12/05 17:38:28, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > why did not we do the same thing for sim1/2 as we did for test_prot_mem1/2, > > i.e., separate mmap and change protection? > > some comment would be helpful here. > > I'll try to write a comment. The simulated sigaction cannot detect memory > protection. (Well, it could, perhaps, using read/write but that would make the > test much more fragile as we'd have to depend on read/write being implemented > correctly.) comment would be nice. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:321: mprotect_nofail(test_edge_base + test_edge_size, test_edge_size, prot2); On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > should these two protection be in the init_test_edge? > > We test with several different memory protections. > > > Also, do you think if it would be better if middle (test_edge_base + > > test_edge_size) as a global var as test_edge_base? > > It could be another value returned from init_test_edge... you are right, my bad, somehow I was thinking prot is set to the same protection, (it must comes from the code below prot = PROT_READ | PROT_WRITE. Do you think if replace 1/2 with more meaning name would be useful? e.g., ret1 => ret_sys, ret2 => ret_sim, prot1 => prot_act, prot2 => prot_oldact. I was thinking about when reading those 1/2 suffix, but not sure if it worth the effort.
Sign in to reply to this message.
https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction0.c (right): https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:33: /* Test sigaction without signals. */ On 2016/12/05 17:41:39, bruening wrote: > Is that what the "0" means? Better to call it sigaction_nosignals.c or > something. I'll make that change. Since it involves renaming a file I'll do it as a separate patch set in case codereview.appspot.com messes up the diff. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:59: struct kernel_sigaction { On 2016/12/05 20:26:36, bruening wrote: > Some consideration should be spent on sharing types with the core which has > these exact definitions: at least a comment on the duplication. I've added a comment. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:67: #define MARGIN 8 On 2016/12/05 20:50:20, zhaoqin wrote: > On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > > On 2016/12/05 16:50:38, zhaoqin wrote: > > > do you mean padding between the array element? > > > > It's a margin used by the test program to detect writes outside the area that > > should be written to. > > better to add that comment. Done. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:167: size_t n = sizeof(test_rw_sys); On 2016/12/05 20:50:20, zhaoqin wrote: > On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > > On 2016/12/05 16:50:38, zhaoqin wrote: > > > nits, use named macro > > > > Why is a named macro better than a named variable? > > named variable would be good. I've decided to call it ... (drum roll) ... sizeof(test_rw_sys). Yes, it turns out I was only using "n" to save typing/reading. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:241: size_t n = sizeof(sim1); On 2016/12/05 20:50:20, zhaoqin wrote: > On 2016/12/05 17:38:28, Edmund.Grimley.Evans wrote: > > On 2016/12/05 16:50:38, zhaoqin wrote: > > > would a named macro with more meaningful name be better? > > > > I'd prefer a named variable. Presumably it's the name you don't like rather > than > > the fact it's a variable? > > > > I tend to use macros only when there is a good reason for not using a > variable. > > in C++, I would use const, so my immediate reaction in C is to use macro replace > const. name variable would be good. Done. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:267: sigsetsize, prot1, prot2); On 2016/12/05 20:50:20, zhaoqin wrote: > On 2016/12/05 17:38:28, Edmund.Grimley.Evans wrote: > > On 2016/12/05 16:50:38, zhaoqin wrote: > > > why did not we do the same thing for sim1/2 as we did for test_prot_mem1/2, > > > i.e., separate mmap and change protection? > > > some comment would be helpful here. > > > > I'll try to write a comment. The simulated sigaction cannot detect memory > > protection. (Well, it could, perhaps, using read/write but that would make the > > test much more fragile as we'd have to depend on read/write being implemented > > correctly.) > > comment would be nice. Added comment above definition of sim_sigaction. https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:321: mprotect_nofail(test_edge_base + test_edge_size, test_edge_size, prot2); On 2016/12/05 17:38:29, Edmund.Grimley.Evans wrote: > On 2016/12/05 16:50:38, zhaoqin wrote: > > should these two protection be in the init_test_edge? > > We test with several different memory protections. > > > Also, do you think if it would be better if middle (test_edge_base + > > test_edge_size) as a global var as test_edge_base? > > It could be another value returned from init_test_edge... The global variable way is probably easiest... https://codereview.appspot.com/311350043/diff/20001/suite/tests/linux/sigacti... suite/tests/linux/sigaction0.c:321: mprotect_nofail(test_edge_base + test_edge_size, test_edge_size, prot2); On 2016/12/05 20:50:20, zhaoqin wrote: > Do you think if replace 1/2 with more meaning name would be useful? > e.g., ret1 => ret_sys, ret2 => ret_sim, prot1 => prot_act, prot2 => prot_oldact. > I was thinking about when reading those 1/2 suffix, but not sure if it worth the > effort. I think I can do that. The important thing is to pick names with the same number of letters so as not to disrupt alignment...
Sign in to reply to this message.
Commit log for latest patchset: --------------- Add test linux.sigaction0, testing sigaction syscall without signals. The "sigaction" system call is fairly complex, even in the absence of signals, and should be emulated accurately by DynamoRIO. The test is disabled as it does not yet pass. Review-URL: https://codereview.appspot.com/311350043 ---------------
Sign in to reply to this message.
Commit log for latest patchset: --------------- Add test linux.sigaction_nosignals, testing syscall without signals. The "sigaction" system call is fairly complex, even in the absence of signals, and should be emulated accurately by DynamoRIO. The test is disabled as it does not yet pass. Review-URL: https://codereview.appspot.com/311350043 ---------------
Sign in to reply to this message.
LGTM with nits. https://codereview.appspot.com/311350043/diff/60001/suite/tests/linux/sigacti... File suite/tests/linux/sigaction_nosignals.c (right): https://codereview.appspot.com/311350043/diff/60001/suite/tests/linux/sigacti... suite/tests/linux/sigaction_nosignals.c:68: #define SIGACT sizeof(struct kernel_sigaction_t) nit, would a name with SIZE be better? https://codereview.appspot.com/311350043/diff/60001/suite/tests/linux/sigacti... suite/tests/linux/sigaction_nosignals.c:75: void kernel_sigdelset(kernel_sigset_t *set, int signum) delset, I understand what it means from the code. Do we have a better name? If no, I am ok with that since the code is short and easy to understand. https://codereview.appspot.com/311350043/diff/60001/suite/tests/linux/sigacti... suite/tests/linux/sigaction_nosignals.c:92: * the memory protection with additional parameters. I assume we could detect the memory protection, just more expensive and fragile maybe. https://codereview.appspot.com/311350043/diff/60001/suite/tests/linux/sigacti... suite/tests/linux/sigaction_nosignals.c:334: if (ret == 0) { nit, could we add comment about why we did not do ret_sim == ret_sys check but check ret_sys == ret and ret_sim == ret only if ret == 0. e.g., xref sim_sigaction
Sign in to reply to this message.
Committed as https://github.com/DynamoRIO/dynamorio/commit/0736badeb79d99c2b0b271f709eaa5a... Final commit log: --------------- Add test linux.sigaction_nosignals, testing syscall without signals. The "sigaction" system call is fairly complex, even in the absence of signals, and should be emulated accurately by DynamoRIO. The test is disabled as it does not yet pass. Review-URL: https://codereview.appspot.com/311350043 ---------------
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
