nativeclient - Project Hosting on Google Code

Today 60 min ago r1097 (Another iteration of the untrusted toolchain creator Review...) committed by robe...@google.com - Another iteration of the untrusted toolchain creator Review URL: http://codereview.chromium.org/477002 Another iteration of the untrusted toolchain creator Review URL: http://codereview.chromium.org/477002 69 min ago issue 182 (GCC for NaCl x64) changed by or...@chromium.org - Cc: or...@chromium.org Labels: Priority-Critical Win64 −Priority-High Cc: or...@chromium.org Labels: Priority-Critical Win64 −Priority-High 70 min ago issue 162 (Deliver 64-bit NaCl compiler) changed by or...@chromium.org - Cc: or...@chromium.org Labels: Priority-Critical −Priority-Medium Cc: or...@chromium.org Labels: Priority-Critical −Priority-Medium 89 min ago issue 199 (2009-12-08 ARM toolchain produces improperly aligned/boxed c...) commented on by cbif...@google.com - I suspect the size is available, but our use of the AsmPrinter is causing it to be ignored. I hadn't considered trying to make the AsmPrinter smarter, and I'm not sure I'm comfortable with that idea...but it does sound pretty simple, so let me take a crack at it. I suspect the size is available, but our use of the AsmPrinter is causing it to be ignored. I hadn't considered trying to make the AsmPrinter smarter, and I'm not sure I'm comfortable with that idea...but it does sound pretty simple, so let me take a crack at it. 91 min ago r1096 (Fix lost check for native_client (x86-64 uses LP64 model, bu...) committed by k...@google.com - Fix lost check for native_client (x86-64 uses LP64 model, but untrusted code uses ILP32 model even in x86-64 mode). Review URL: http://codereview.chromium.org/480001 Fix lost check for native_client (x86-64 uses LP64 model, but untrusted code uses ILP32 model even in x86-64 mode). Review URL: http://codereview.chromium.org/480001 94 min ago issue 202 (ARM toolchain is applying -static to all linker calls) changed by cbif...@google.com - NaCl's ARM target is basically Ubuntu 9.10 now, so we're less likely to have surprising library incompatibilities than we were when using e.g. Angstrom. The plugin doesn't actually have -static on it (in the scons), so there's nothing to remove there. This environment variable seems to be the main source of breakage there. I think I might have a working plugin today (modulo the validation failures in some of the code), so I'll reassign this bug to myself. Status: Started Owner: cbif...@google.com Cc: robe...@google.com NaCl's ARM target is basically Ubuntu 9.10 now, so we're less likely to have surprising library incompatibilities than we were when using e.g. Angstrom. The plugin doesn't actually have -static on it (in the scons), so there's nothing to remove there. This environment variable seems to be the main source of breakage there. I think I might have a working plugin today (modulo the validation failures in some of the code), so I'll reassign this bug to myself. Status: Started Owner: cbif...@google.com Cc: robe...@google.com 2 hours ago r1095 (Fix an apparent commenting error in ncopcode_operand_kind.en...) committed by bradc...@google.com - Fix an apparent commenting error in ncopcode_operand_kind.enum. I'm not sure why this actually worked. Review URL: http://codereview.chromium.org/455033 Fix an apparent commenting error in ncopcode_operand_kind.enum. I'm not sure why this actually worked. Review URL: http://codereview.chromium.org/455033 2 hours ago r1094 (Fix broken build - if SDK type is not specified it's 32bit v...) committed by k...@google.com - Fix broken build - if SDK type is not specified it's 32bit version Review URL: http://codereview.chromium.org/477003 Fix broken build - if SDK type is not specified it's 32bit version Review URL: http://codereview.chromium.org/477003 3 hours ago r1093 (Fix naclsdk.py to make it compileable with nacl64 SDK. Inste...) committed by k...@google.com - Fix naclsdk.py to make it compileable with nacl64 SDK. Instead of custiom: we are using custom64: here. Review URL: http://codereview.chromium.org/475001 Fix naclsdk.py to make it compileable with nacl64 SDK. Instead of custiom: we are using custom64: here. Review URL: http://codereview.chromium.org/475001 3 hours ago issue 185 (Service Runtime for NaCl on 64 bit Windows) Owner changed by bradc...@google.com - Owner: ile...@google.com Owner: ile...@google.com 3 hours ago issue 26 (Plugin Installed, Firefox 3.0.4 Crash in Windows XP SP 2 @ A...) Owner changed by bradc...@google.com - Owner: ile...@google.com Owner: ile...@google.com 5 hours ago issue 199 (2009-12-08 ARM toolchain produces improperly aligned/boxed c...) commented on by robe...@google.com - good catch! Please check whether the total size of the object is available at the place where we emit sfi_illegal_if_at_bundle_begining if yes I can help you with figuring out a proper "align-if-macro" analogous to what we do for sfi coding sequence. It would also be good to assert that the object is no larger than 12 bytes. good catch! Please check whether the total size of the object is available at the place where we emit sfi_illegal_if_at_bundle_begining if yes I can help you with figuring out a proper "align-if-macro" analogous to what we do for sfi coding sequence. It would also be good to assert that the object is no larger than 12 bytes. 6 hours ago issue 202 (ARM toolchain is applying -static to all linker calls) commented on by robe...@google.com - proposal: making every thing static helps a lot when copying images to devices that may not have the same set of shared libs. How about: * removing the -static as you mentioned (and maybe all the other flags, except for linkerscript stuff) * move those into scons as you suggested * [new] explicitly remove -static for the plugin proposal: making every thing static helps a lot when copying images to devices that may not have the same set of shared libs. How about: * removing the -static as you mentioned (and maybe all the other flags, except for linkerscript stuff) * move those into scons as you suggested * [new] explicitly remove -static for the plugin 7 hours ago r1092 (fixit: GCC build on win32 and atomic_ops on all 64 bit syste...) committed by pa...@google.com - fixit: GCC build on win32 and atomic_ops on all 64 bit systems. Review URL: http://codereview.chromium.org/463066 fixit: GCC build on win32 and atomic_ops on all 64 bit systems. Review URL: http://codereview.chromium.org/463066 18 hours ago issue 202 (ARM toolchain is applying -static to all linker calls) commented on by cbif...@google.com - Initial testing suggests that simply removing this fixes everything. CL to follow once I'm comfortable that this was vestigial. Initial testing suggests that simply removing this fixes everything. CL to follow once I'm comfortable that this was vestigial. 18 hours ago issue 138 (Need sandboxed libgcc for ARM) commented on by cbif...@google.com - This is still a work in progress -- the libgcc.a distributed with the current prototype toolchain unfortunately contains some Thumb implementations of certain functions (_umodsi3 for example), causing Thumb calls in generated code. These don't validate. Recompilation with more aggressive settings ("--disable-thumb" among others) is in order. This is still a work in progress -- the libgcc.a distributed with the current prototype toolchain unfortunately contains some Thumb implementations of certain functions (_umodsi3 for example), causing Thumb calls in generated code. These don't validate. Recompilation with more aggressive settings ("--disable-thumb" among others) is in order. 18 hours ago issue 201 (Start ISE review for NaCl ARM) commented on by bradc...@google.com - The internal ISE security review is a critical step towards production readiness. The trusted code base needs to basically be feature complete before it can begin. ISE reviews are started by sending mail to the ISE team, but before we do that we'll want to agree internally that we are ready. The internal ISE security review is a critical step towards production readiness. The trusted code base needs to basically be feature complete before it can begin. ISE reviews are started by sending mail to the ISE team, but before we do that we'll want to agree internally that we are ready. 19 hours ago issue 121 (Plugin is building with a weird mix of -fPIC and non-fPIC co...) Blocked on changed by cbif...@google.com - 19 hours ago issue 202 (ARM toolchain is applying -static to all linker calls) reported by cbif...@google.com - Using the 2009-12-08 ARM toolchain setup scripts, we export ARM_LINKFLAGS="- static". This causes all compilation -- even in cases where we're building a shared object -- to include -static on its linker command line. This is breaking at least the plugin. If we need -static it should be in the scons files, not the environment. Using the 2009-12-08 ARM toolchain setup scripts, we export ARM_LINKFLAGS="- static". This causes all compilation -- even in cases where we're building a shared object -- to include -static on its linker command line. This is breaking at least the plugin. If we need -static it should be in the scons files, not the environment. 19 hours ago issue 201 (Start ISE review for NaCl ARM) reported by bradc...@google.com - The ISE review is a prerequisite for Beta, external security review, and many things that follow... The ISE review is a prerequisite for Beta, external security review, and many things that follow... 19 hours ago issue 200 (Start ISE review for NaCl x86-64) reported by bradc...@google.com - Complete ISE review for NaCl x86-64 sandbox, in preparation for beta release and all that follows. Complete ISE review for NaCl x86-64 sandbox, in preparation for beta release and all that follows. 19 hours ago issue 154 (integrate Nacl64 changes for GCC (4.4)) Owner changed by or...@chromium.org - Owner: pa...@google.com Owner: pa...@google.com 19 hours ago issue 122 (GCC-x86-64: fix tail recursion bug) Owner changed by or...@chromium.org - Owner: pa...@google.com Owner: pa...@google.com 19 hours ago issue 182 (GCC for NaCl x64) changed by or...@chromium.org - Summary: GCC for NaCl x64 Status: Assigned Labels: Milestone-GLQuake-x86-64 −Milestone-GLQuake-x86-32 Summary: GCC for NaCl x64 Status: Assigned Labels: Milestone-GLQuake-x86-64 −Milestone-GLQuake-x86-32 19 hours ago 2 issues changed by or...@chromium.org - Issues 26, 102 Issues 26, 102 20 hours ago issue 199 (2009-12-08 ARM toolchain produces improperly aligned/boxed c...) reported by cbif...@google.com - Using the 2009-12-08 toolchain to compile libgcc, some constant pools are not being generated correctly. This may not be a regression, since to my knowledge I'm the first one to really push on our VFP support. Because the macro we use to align constant pools (and generate the pool header) can't look ahead, it doesn't handle constants of >4 bytes well. An example (from _muldc3 in libgcc): .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_3: .zero 8 @ BB#37: .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_0: .long 0 @ least significant word of double 1.000000e+00 .long 1072693248 @ most significant word of double 1.000000e+00 This generates the following: 3e0: e1277777 bkpt 0x7777 3e4: 00000000 .word 0 3e8: 00000000 .word 0 3ec: 00000000 .word 0 3f0: 3ff00000 .word 0x3ff00000 One could look at this two different ways: 1. The bug is in LLVM, which is generating eight-byte constants using pairs of four-byte constant directives, and this breaks our macro. 2. The bug is in our macro, which doesn't know the size of the constant pool entry it's about to handle and doesn't know to pad out in advance. Really the long-term fix is to move the padding and bundling logic into the code generator, which does know how big the CPEs are. Using the 2009-12-08 toolchain to compile libgcc, some constant pools are not being generated correctly. This may not be a regression, since to my knowledge I'm the first one to really push on our VFP support. Because the macro we use to align constant pools (and generate the pool header) can't look ahead, it doesn't handle constants of >4 bytes well. An example (from _muldc3 in libgcc): .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_3: .zero 8 @ BB#37: .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_0: .long 0 @ least significant word of double 1.000000e+00 .long 1072693248 @ most significant word of double 1.000000e+00 This generates the following: 3e0: e1277777 bkpt 0x7777 3e4: 00000000 .word 0 3e8: 00000000 .word 0 3ec: 00000000 .word 0 3f0: 3ff00000 .word 0x3ff00000 One could look at this two different ways: 1. The bug is in LLVM, which is generating eight-byte constants using pairs of four-byte constant directives, and this breaks our macro. 2. The bug is in our macro, which doesn't know the size of the constant pool entry it's about to handle and doesn't know to pad out in advance. Really the long-term fix is to move the padding and bundling logic into the code generator, which does know how big the CPEs are. 22 hours ago issue 196 (ARM sel_ldr/validator interface rejects all binaries) Status changed by cbif...@google.com - http://codereview.chromium.org/460120 Status: Fixed http://codereview.chromium.org/460120 Status: Fixed 22 hours ago r1091 (The ARM validator's interface to the sel_ldr contains specia...) committed by cbif...@google.com - The ARM validator's interface to the sel_ldr contains specialized code (the EarlyExitProblemSink) that causes validation to abort as soon as an error is found. (Contrast with the logic in arm- ncval-core, which collects all errors to build a report.) Unfortunately, because ARM validation has been disabled across the board, this code was never well tested (my mistake!) and has always contained a fatal flaw. The should_continue method may be called at any time, not just when a problem is found, so simply returning false isn't correct. This CL does not contain a test because of interdependencies with our buildbots and the ARM toolchain (which is not in SVN). A fix needs to go into the toolchain and be deployed to the bots before the test for this CL can go in. Sigh. BUG=196 Review URL: http://codereview.chromium.org/460120 The ARM validator's interface to the sel_ldr contains specialized code (the EarlyExitProblemSink) that causes validation to abort as soon as an error is found. (Contrast with the logic in arm- ncval-core, which collects all errors to build a report.) Unfortunately, because ARM validation has been disabled across the board, this code was never well tested (my mistake!) and has always contained a fatal flaw. The should_continue method may be called at any time, not just when a problem is found, so simply returning false isn't correct. This CL does not contain a test because of interdependencies with our buildbots and the ARM toolchain (which is not in SVN). A fix needs to go into the toolchain and be deployed to the bots before the test for this CL can go in. Sigh. BUG=196 Review URL: http://codereview.chromium.org/460120 22 hours ago r1090 (add toolchain sdk creation script just for trusted arm part ...) committed by robe...@google.com - add toolchain sdk creation script just for trusted arm part NOTE: this toolchain is based on coddesourcery 2009Q3 Review URL: http://codereview.chromium.org/464071 add toolchain sdk creation script just for trusted arm part NOTE: this toolchain is based on coddesourcery 2009Q3 Review URL: http://codereview.chromium.org/464071 22 hours ago r1089 (Fix 64-bit validator to handle 66 and CS code segment prefic...) committed by kschi...@google.com - Fix 64-bit validator to handle 66 and CS code segment prefices specially. Review URL: http://codereview.chromium.org/464066 Fix 64-bit validator to handle 66 and CS code segment prefices specially. Review URL: http://codereview.chromium.org/464066 23 hours ago r1088 (add qemu tarball needed for arm sdk Review URL: http://code...) committed by robe...@google.com - add qemu tarball needed for arm sdk Review URL: http://codereview.chromium.org/466010 add qemu tarball needed for arm sdk Review URL: http://codereview.chromium.org/466010 23 hours ago r1087 (Do-over for 64-bit IMC patch. Cleans up several 64-bit port...) committed by ile...@google.com - Do-over for 64-bit IMC patch. Cleans up several 64-bit portability issues in _types and nacl_imc. Review URL: http://codereview.chromium.org/460143 Do-over for 64-bit IMC patch. Cleans up several 64-bit portability issues in _types and nacl_imc. Review URL: http://codereview.chromium.org/460143 Yesterday 27 hours ago issue 140 (mmap should stop all other threads prior to opening up the m...) Owner changed by bradc...@google.com - Owner: b...@google.com Owner: b...@google.com 27 hours ago issue 136 (runtime code generation) Owner changed by bradc...@google.com - Owner: b...@google.com Owner: b...@google.com 43 hours ago issue 195 (ARM validator should be on, by default, for everything) Blocked on changed by cbif...@google.com - 44 hours ago r1086 (* Removed apparently unnecessary dependency on libssl * swit...) committed by robe...@google.com - * Removed apparently unnecessary dependency on libssl * switched arm compile mode to armv6 Review URL: http://codereview.chromium.org/460122 * Removed apparently unnecessary dependency on libssl * switched arm compile mode to armv6 Review URL: http://codereview.chromium.org/460122 45 hours ago issue 197 (Code review site links NativeClient changes to Chromium's is...) reported by cbif...@google.com - When submitting a CL to NativeClient's source code repository (here on Google Code) we use codereview.chromium.org for the review process. Best practices suggest we include a BUG=xxx line in the CL description to reference the issue we're working on. However, when we do this, the link goes to Chromium's issue tracker, not ours. When submitting a CL to NativeClient's source code repository (here on Google Code) we use codereview.chromium.org for the review process. Best practices suggest we include a BUG=xxx line in the CL description to reference the issue we're working on. However, when we do this, the link goes to Chromium's issue tracker, not ours. 45 hours ago r1085 (Simple validator fixes to start to bring it into alignment i...) committed by bradc...@google.com - Simple validator fixes to start to bring it into alignment into compiler, and facilitate compiler testing. Specific changes: * made one variant of movsxd legal that was previously marked illegal. * made a jump to address 0 a validation error instead of assert(0). Review URL: http://codereview.chromium.org/458009 Simple validator fixes to start to bring it into alignment into compiler, and facilitate compiler testing. Specific changes: * made one variant of movsxd legal that was previously marked illegal. * made a jump to address 0 a validation error instead of assert(0). Review URL: http://codereview.chromium.org/458009 45 hours ago r1084 (Modify validator so that default behaviour is to stop after ...) committed by kschi...@google.com - Modify validator so that default behaviour is to stop after the first validation error. To override this (and get all errors), one must use the command line argument "-all_errors". Review URL: http://codereview.chromium.org/455014 Modify validator so that default behaviour is to stop after the first validation error. To override this (and get all errors), one must use the command line argument "-all_errors". Review URL: http://codereview.chromium.org/455014 45 hours ago issue 195 (ARM validator should be on, by default, for everything) Blocked on changed by cbif...@google.com - 46 hours ago r1083 (I think this makes the code a little bit safer as it evolves...) committed by bradc...@google.com - I think this makes the code a little bit safer as it evolves. Yes? Review URL: http://codereview.chromium.org/465098 I think this makes the code a little bit safer as it evolves. Yes? Review URL: http://codereview.chromium.org/465098 47 hours ago issue 195 (ARM validator should be on, by default, for everything) Blocked on changed by cbif...@google.com - Initial changes revealed one bug so far! Initial changes revealed one bug so far! 47 hours ago issue 196 (ARM sel_ldr/validator interface rejects all binaries) reported by cbif...@google.com - In the ARM sel_ldr as of SVN r1082, we reject all binaries with validation errors -- even binaries that validate under the command line ncval tool. To reproduce with the newest toolchain, remove the "-d" flag from the topmost build.scons and attempt to run the tests under platform=arm. This appears to be a bug in ncvalidate.cc for the new ARM validator. CL to follow. In the ARM sel_ldr as of SVN r1082, we reject all binaries with validation errors -- even binaries that validate under the command line ncval tool. To reproduce with the newest toolchain, remove the "-d" flag from the topmost build.scons and attempt to run the tests under platform=arm. This appears to be a bug in ncvalidate.cc for the new ARM validator. CL to follow. 47 hours ago issue 195 (ARM validator should be on, by default, for everything) reported by cbif...@google.com - Currently, the ARM build and tests disable validation of nexes by default. This dates back to the days when the validator was young and immature, and when the equally young toolchain produced some sequences that were known to be invalid. We think we've got all these issues fixed, so we should turn on the validator for everything. If we have any remaining bugs in the toolchain (or validator) this should help flush them out. This is likely to involve - Removing the -d (debug) and -I (ignore ABI violations) switches from all ARM targets -- both at the top level and in the tests/ build files. - Fixing any issues that result (e.g. failing to set ELF headers correctly in the toolchain). - Some number of unforeseen test breakages that these settings were hiding! Currently, the ARM build and tests disable validation of nexes by default. This dates back to the days when the validator was young and immature, and when the equally young toolchain produced some sequences that were known to be invalid. We think we've got all these issues fixed, so we should turn on the validator for everything. If we have any remaining bugs in the toolchain (or validator) this should help flush them out. This is likely to involve - Removing the -d (debug) and -I (ignore ABI violations) switches from all ARM targets -- both at the top level and in the tests/ build files. - Fixing any issues that result (e.g. failing to set ELF headers correctly in the toolchain). - Some number of unforeseen test breakages that these settings were hiding! Last 7 days Dec 07, 2009 issue 138 (Need sandboxed libgcc for ARM) changed by cbif...@google.com - Owner: cbif...@google.com Labels: Arch-ARM Owner: cbif...@google.com Labels: Arch-ARM Dec 05, 2009 r1082 (Minor whitespace change--just need something to kick off a f...) committed by ile...@google.com - Minor whitespace change--just need something to kick off a fresh build so that the buildbots will pick up a fresh sdk. Review URL: http://codereview.chromium.org/467034 Minor whitespace change--just need something to kick off a fresh build so that the buildbots will pick up a fresh sdk. Review URL: http://codereview.chromium.org/467034 Dec 05, 2009 r1081 (Last attempt to patch this change. Backed out some overzealo...) committed by ile...@google.com - Last attempt to patch this change. Backed out some overzealous makefile modifications--I meant to remove references to the nacl_imc header, not the whole library. :-P Last attempt to patch this change. Backed out some overzealous makefile modifications--I meant to remove references to the nacl_imc header, not the whole library. :-P Dec 04, 2009 r1080 (Revert change 1076 and subsequent attempts to fix the build....) committed by ile...@google.com - Revert change 1076 and subsequent attempts to fix the build. It's late. I'll tackle this again tomorrow. TBR: sehr Review URL: http://codereview.chromium.org/466052 Revert change 1076 and subsequent attempts to fix the build. It's late. I'll tackle this again tomorrow. TBR: sehr Review URL: http://codereview.chromium.org/466052 Dec 04, 2009 r1079 (More makefiles that slipped past my first grep Review URL: ...) committed by ile...@google.com - More makefiles that slipped past my first grep Review URL: http://codereview.chromium.org/460099 More makefiles that slipped past my first grep Review URL: http://codereview.chromium.org/460099 Dec 04, 2009 r1078 (<sigh> tried to make lint happy by using the full directory ...) committed by ile...@google.com - <sigh> tried to make lint happy by using the full directory in a #include, only to find out that the include path isn't set up for that. Review URL: http://codereview.chromium.org/467033 <sigh> tried to make lint happy by using the full directory in a #include, only to find out that the include path isn't set up for that. Review URL: http://codereview.chromium.org/467033

issue 199 (2009-12-08 ARM toolchain produces improperly aligned/boxed c...) reported by cbif...@google.com - Using the 2009-12-08 toolchain to compile libgcc, some constant pools are not being generated correctly. This may not be a regression, since to my knowledge I'm the first one to really push on our VFP support. Because the macro we use to align constant pools (and generate the pool header) can't look ahead, it doesn't handle constants of >4 bytes well. An example (from _muldc3 in libgcc): .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_3: .zero 8 @ BB#37: .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_0: .long 0 @ least significant word of double 1.000000e+00 .long 1072693248 @ most significant word of double 1.000000e+00 This generates the following: 3e0: e1277777 bkpt 0x7777 3e4: 00000000 .word 0 3e8: 00000000 .word 0 3ec: 00000000 .word 0 3f0: 3ff00000 .word 0x3ff00000 One could look at this two different ways: 1. The bug is in LLVM, which is generating eight-byte constants using pairs of four-byte constant directives, and this breaks our macro. 2. The bug is in our macro, which doesn't know the size of the constant pool entry it's about to handle and doesn't know to pad out in advance. Really the long-term fix is to move the padding and bundling logic into the code generator, which *does* know how big the CPEs are.

Using the 2009-12-08 toolchain to compile libgcc, some constant pools are not being generated correctly. This may not be a regression, since to my knowledge I'm the first one to really push on our VFP support. Because the macro we use to align constant pools (and generate the pool header) can't look ahead, it doesn't handle constants of >4 bytes well. An example (from _muldc3 in libgcc): .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_3: .zero 8 @ BB#37: .align 2 sfi_illegal_if_at_bundle_begining .LCPI1_0: .long 0 @ least significant word of double 1.000000e+00 .long 1072693248 @ most significant word of double 1.000000e+00 This generates the following: 3e0: e1277777 bkpt 0x7777 3e4: 00000000 .word 0 3e8: 00000000 .word 0 3ec: 00000000 .word 0 3f0: 3ff00000 .word 0x3ff00000 One could look at this two different ways: 1. The bug is in LLVM, which is generating eight-byte constants using pairs of four-byte constant directives, and this breaks our macro. 2. The bug is in our macro, which doesn't know the size of the constant pool entry it's about to handle and doesn't know to pad out in advance. Really the long-term fix is to move the padding and bundling logic into the code generator, which *does* know how big the CPEs are.

Today

Yesterday

Last 7 days