2011-10-31T00:13:12 *** xiangfu has quit IRC (Ping timeout: 240 seconds) 2011-10-31T00:25:46 *** xiangfu has joined #rtems 2011-10-31T01:00:40 *** xiangfu has quit IRC (Ping timeout: 260 seconds) 2011-10-31T01:12:31 *** xiangfu has joined #rtems 2011-10-31T01:19:11 *** xiangfu has quit IRC (Ping timeout: 252 seconds) 2011-10-31T01:58:47 *** xiangfu has joined #rtems 2011-10-31T02:09:12 *** xiangfu has quit IRC (Ping timeout: 240 seconds) 2011-10-31T02:19:59 *** peerst has quit IRC (Ping timeout: 258 seconds) 2011-10-31T02:22:39 *** xiangfu has joined #rtems 2011-10-31T04:42:38 *** xiangfu has quit IRC (Ping timeout: 256 seconds) 2011-10-31T05:27:42 *** methril_work has joined #rtems 2011-10-31T06:12:34 *** peerst has joined #rtems 2011-10-31T07:06:47 *** rtemsLogger has joined #rtems 2011-10-31T07:09:06 *** timakima has joined #rtems 2011-10-31T07:11:54 *** arvind_khadri has joined #rtems 2011-10-31T08:33:50 *** pzagor has joined #rtems 2011-10-31T08:55:28 *** pzagor has quit IRC (Ping timeout: 265 seconds) 2011-10-31T09:10:24 *** arvind_khadri has quit IRC (Ping timeout: 248 seconds) 2011-10-31T09:23:10 *** arvind_khadri has joined #rtems 2011-10-31T09:23:11 *** arvind_khadri has joined #rtems 2011-10-31T11:10:11 *** neo1987___ has joined #rtems 2011-10-31T11:11:08 *** neo1987___ has joined #rtems 2011-10-31T11:11:19 hello 2011-10-31T11:12:16 is there anyone? 2011-10-31T11:21:25 *** neo1987___ has quit IRC (Read error: Connection reset by peer) 2011-10-31T11:21:43 *** neo1987___ has joined #rtems 2011-10-31T11:29:47 *** antgreen has joined #rtems 2011-10-31T11:40:20 do you know when i can find Dr_Joel? 2011-10-31T11:49:00 you mean here? 2011-10-31T11:53:07 yes 2011-10-31T12:05:32 I have not seem DrJoel very often here 2011-10-31T12:05:42 why don't you just email him 2011-10-31T12:06:01 s/seem/seen/ 2011-10-31T12:29:38 I already sent an e-mail. 2011-10-31T12:30:13 and I already have written to the mailing list 2011-10-31T12:31:17 So i'll try to solve my problem alone waiting his connection here 2011-10-31T12:38:13 *** arvind_khadri has quit IRC (Ping timeout: 240 seconds) 2011-10-31T13:33:40 *** arvind_khadri has joined #rtems 2011-10-31T13:53:56 neo1987__ I don't remember seeing you on the mailing list ... what was your question? 2011-10-31T14:24:27 my e-mail used in the mailing list is dar.imparato@studenti.unina.it 2011-10-31T14:29:57 I sent an e-mail the 20/10/11 0:07 for object: "Qemu version for rtems-testing" 2011-10-31T14:30:52 asking which version of qemu must be used for rtems-testing scripts 2011-10-31T14:31:53 for i386 target pc386 BSP 2011-10-31T14:34:43 the last couverture-qemu is not compatible with the last pc386 script of rtems-testing module 2011-10-31T14:35:55 do you understand? 2011-10-31T15:13:36 *** methril has quit IRC (Ping timeout: 240 seconds) 2011-10-31T15:14:25 *** neo1987___ has left #rtems 2011-10-31T15:26:13 *** methril has joined #rtems 2011-10-31T18:03:04 *** xiangfu has joined #rtems 2011-10-31T18:03:23 *** methril has quit IRC (Quit: Leaving) 2011-10-31T18:36:44 *** xiangfu has quit IRC (Ping timeout: 256 seconds) 2011-10-31T19:20:29 *** xiangfu has joined #rtems 2011-10-31T20:44:54 *** kiwichris has quit IRC (Ping timeout: 265 seconds) 2011-10-31T20:50:08 *** kiwichris has joined #rtems 2011-10-31T21:56:26 *** kiwichris has quit IRC (Ping timeout: 265 seconds) 2011-10-31T22:34:35 *** kiwichris has joined #rtems 2011-10-31T23:22:14 *** arvind_khadri has quit IRC (Quit: Leaving) 2011-10-31T23:22:59 *** arvind_khadri has joined #rtems 2011-10-31T23:22:59 *** arvind_khadri has joined #rtems 2011-10-31T23:25:28 *** arvind_k has joined #rtems 2011-10-31T23:28:33 *** arvind_khadri has quit IRC (Ping timeout: 276 seconds) 2011-10-31T23:44:03 *** antgreen has quit IRC (Ping timeout: 255 seconds) 2011-11-01T00:17:01 *** arvind_k has quit IRC (Ping timeout: 240 seconds) 2011-11-01T01:24:58 *** arvind_khadri has joined #rtems 2011-11-01T01:30:40 *** arvind_khadri has quit IRC (Quit: Leaving) 2011-11-01T01:40:21 *** xiangfu has quit IRC (Ping timeout: 252 seconds) 2011-11-01T02:06:40 *** xiangfu has joined #rtems 2011-11-01T02:14:21 *** monstr-rtems has joined #rtems 2011-11-01T02:24:11 *** arvind_khadri has joined #rtems 2011-11-01T02:35:21 *** arvind_khadri has quit IRC (Quit: Leaving) 2011-11-01T02:36:28 *** arvind_khadri has joined #rtems 2011-11-01T03:08:19 *** timakima has quit IRC (Ping timeout: 244 seconds) 2011-11-01T03:14:30 *** timakima has joined #rtems 2011-11-01T03:30:48 *** arvind_khadri has quit IRC (Ping timeout: 240 seconds) 2011-11-01T04:27:14 *** arvind_khadri has joined #rtems 2011-11-01T05:17:06 *** antgreen has joined #rtems 2011-11-01T06:31:05 *** arvind_khadri has quit IRC (Ping timeout: 260 seconds) 2011-11-01T06:59:51 *** arvind_khadri has joined #rtems 2011-11-01T07:21:09 *** antgreen has quit IRC (Remote host closed the connection) 2011-11-01T08:54:48 *** arvind_khadri has quit IRC (Ping timeout: 240 seconds) 2011-11-01T09:38:38 *** arvind_khadri has joined #rtems 2011-11-01T09:38:38 *** arvind_khadri has joined #rtems 2011-11-01T09:58:02 *** arvind_khadri has quit IRC (Quit: Leaving) 2011-11-01T10:04:58 *** xiangfu has quit IRC (Ping timeout: 258 seconds) 2011-11-01T10:12:43 *** antgreen has joined #rtems 2011-11-01T10:49:56 *** gedare has joined #rtems 2011-11-01T11:05:07 *** antgreen has quit IRC (Remote host closed the connection) 2011-11-01T11:59:35 *** neo1987___ has joined #rtems 2011-11-01T12:00:02 *** neo1987___ has joined #rtems 2011-11-01T12:00:08 hello 2011-11-01T12:06:54 I have read your mail 2011-11-01T12:07:35 sounds to me that a solution is more likely to be found from the qemu community 2011-11-01T12:08:11 you are not getting an answer because probably nobody knows 2011-11-01T12:15:13 i made it but noone can help me in qemu community 2011-11-01T12:16:15 Only who created pc386 script for rtems-testing module can help me, because I have to know what version he used. 2011-11-01T12:18:55 and the author is DrJoel 2011-11-01T12:21:06 he was here the other day, but he has been travelling last few weeks so I think he is still backlogged 2011-11-01T12:23:41 neo1987__: why not fix the script so it runs with the latest qemu? 2011-11-01T12:25:37 i tried to fix it but then a damaged .cov file was created. 2011-11-01T12:26:06 Maybe i badly fixed it 2011-11-01T12:26:18 probably :-) 2011-11-01T12:26:26 otherwise it would work 2011-11-01T12:26:32 the old option was qemu -trace file.cov 2011-11-01T12:26:46 from the script? 2011-11-01T12:26:52 yes 2011-11-01T12:27:01 and the new one? 2011-11-01T12:29:42 -trace [events=file][,file=file] 2011-11-01T12:29:43 Specify tracing options. 2011-11-01T12:29:43 events=file 2011-11-01T12:29:43 Immediately enable events listed in file. The file must contain one event name (as listed in the trace-events file) per line. This option is only available if QEMU has been compiled with either simple or stderr tracing backend. 2011-11-01T12:29:43 file=file 2011-11-01T12:29:43 Log output traces to file. 2011-11-01T12:29:43 This option is only available if QEMU has been compiled with the simple tracing backend. 2011-11-01T12:31:37 but the qemu people should know how to get the behaviour of qemu -trace with the new quemu options 2011-11-01T12:32:43 so i compiled qemu with the option --enable-trace-backend=simple 2011-11-01T12:32:47 unless the -trace flag from before was patched in by the couverture folks and the new flag is from the qemu people. but the couverture people should know it. 2011-11-01T12:33:06 Just ask them that you have a script with qemu -tace file and how you should specify the new option to get the new effect 2011-11-01T12:33:34 gedare: disclaimer I know nothing of quemu 2011-11-01T12:33:57 but somebody did change the option and they should know 2011-11-01T12:34:03 :) I think joel was using a patched qemu that had a -trace flag, and I suspect qemu added their own -trace flag 2011-11-01T12:34:28 DrJoel probably would have to ask the same question you will have to ask them to find out what changed 2011-11-01T12:34:42 gedare: :-o 2011-11-01T12:34:55 in this case you really need to ask him 2011-11-01T12:35:31 neo1987___: which script are you using? 2011-11-01T12:39:10 In previous versions of qemu-couverture there were versions which used -trace file.cov option (as used from DrJoel) so i tried different older versions but have other bugs (segmentation faults). The script that has the bug is pc386 in rtems-testing/sim-scripts. 2011-11-01T12:39:48 I will ask how to convert the previous -trace .cov with the new format in qemu channel 2011-11-01T12:40:27 (I fixed pc386 script simply converting in "qemu -trace file=file.cov" ) 2011-11-01T12:41:00 so I ask and report the answer 2011-11-01T12:41:38 see you later 2011-11-01T12:41:40 *** neo1987___ has left #rtems 2011-11-01T12:52:40 *** methril_work has quit IRC (Ping timeout: 244 seconds) 2011-11-01T12:57:12 *** monstr-rtems has quit IRC (Read error: Operation timed out) 2011-11-01T13:12:58 *** gedare has quit IRC (Quit: Ex-Chat) 2011-11-01T14:09:35 *** gedare has joined #rtems 2011-11-01T17:26:51 *** gedare has quit IRC (Quit: Ex-Chat) 2011-11-01T18:20:50 *** neo1987___ has joined #rtems 2011-11-01T18:21:21 here I am 2011-11-01T18:59:40 *** neo1987___ has quit IRC () 2011-11-01T19:12:43 *** subodh has joined #rtems 2011-11-01T19:12:57 anyone here? 2011-11-01T19:16:47 hi 2011-11-01T19:17:02 hi chris.. thanks for helping me other day 2011-11-01T19:17:10 No probs 2011-11-01T19:17:56 I am back digging into qemu stuff (I know this is not the right place.., but irc.oftc.net channel for qemu isn't working well.) 2011-11-01T19:18:11 Ok 2011-11-01T19:18:20 do you know any where else I can get more info on qemu? 2011-11-01T19:20:19 What is the issue ? 2011-11-01T19:21:10 I would like to bring up ppc emulation with RTEMS and application file. I don't want to bring up Linux/harddrive based OS etc. 2011-11-01T19:21:41 is there a RTEMS example for doing that? 2011-11-01T19:21:48 There is a qemu-discussion list. I would try IRC again. 2011-11-01T19:22:25 It would be good to get this working as qemu is heading to a 1.0 freeze 2011-11-01T19:22:56 There is also a powerpc mailing list. 2011-11-01T19:23:18 The qemu developers list is +200 emails a day 2011-11-01T19:23:45 great.. good to know. I will go register. 2011-11-01T19:23:51 thanks a bunch. 2011-11-01T19:25:12 Ping me if you need anything. I am looking after m68k for qemu now. 2011-11-01T19:26:56 *** kiwichris has quit IRC (Quit: Leaving) 2011-11-01T19:27:38 *** kiwichris has joined #rtems 2011-11-01T19:28:38 chris.. in the devel list I found some reference to mcp750 + RTEMS based qemu boot up support. I will dig more and perhaps email you tomorrow. 2011-11-01T19:28:51 Ok 2011-11-01T19:28:54 That was great help, I got to go home now, though. 2011-11-01T19:29:03 have a good day :-) 2011-11-01T19:29:03 bye 2011-11-01T19:29:14 Will do. Lovely spring day in Sydney 2011-11-01T20:04:51 *** xiangfu has joined #rtems 2011-11-02T00:19:09 *** mwalle has quit IRC (Ping timeout: 260 seconds) 2011-11-02T00:19:44 *** timakima has quit IRC (Ping timeout: 260 seconds) 2011-11-02T00:19:44 *** mwalle has joined #rtems 2011-11-02T00:19:48 *** timakima has joined #rtems 2011-11-02T01:29:05 *** monstr-rtems has joined #rtems 2011-11-02T02:05:48 *** xiangfu has quit IRC (Ping timeout: 252 seconds) 2011-11-02T02:24:55 *** xiangfu has joined #rtems 2011-11-02T04:24:55 *** xiangfu has quit IRC (Quit: Leaving) 2011-11-02T05:28:22 *** subodh has quit IRC (*.net *.split) 2011-11-02T05:28:22 *** kiwichris has quit IRC (*.net *.split) 2011-11-02T05:28:22 *** mwalle has quit IRC (*.net *.split) 2011-11-02T05:28:24 *** verm__ has quit IRC (*.net *.split) 2011-11-02T05:28:26 *** lcpfnvcy has quit IRC (*.net *.split) 2011-11-02T05:28:26 *** dr__house has quit IRC (*.net *.split) 2011-11-02T05:28:27 *** demute has quit IRC (*.net *.split) 2011-11-02T05:28:27 *** ChanServ has quit IRC (*.net *.split) 2011-11-02T05:32:34 *** lcpfnvcy has joined #rtems 2011-11-02T05:32:34 *** verm__ has joined #rtems 2011-11-02T05:32:34 *** dr__house has joined #rtems 2011-11-02T05:33:12 *** mwalle has joined #rtems 2011-11-02T05:39:13 *** demute has joined #rtems 2011-11-02T05:51:43 *** subodh has joined #rtems 2011-11-02T05:51:43 *** ChanServ has joined #rtems 2011-11-02T05:51:43 *** pratchett.freenode.net sets mode: +o ChanServ 2011-11-02T05:59:46 *** kiwichris has joined #rtems 2011-11-02T08:08:13 *** pzagor has joined #rtems 2011-11-02T08:30:50 *** neo1987___ has joined #rtems 2011-11-02T08:31:02 hello 2011-11-02T08:41:38 *** pzagor has quit IRC (Ping timeout: 265 seconds) 2011-11-02T09:15:57 *** gedare has joined #rtems 2011-11-02T10:21:59 *** antgreen has joined #rtems 2011-11-02T11:57:02 *** neo1987___ has quit IRC () 2011-11-02T12:33:33 *** antgreen` has joined #rtems 2011-11-02T12:33:54 *** antgreen has quit IRC (Read error: Connection reset by peer) 2011-11-02T12:33:54 *** antgreen` has quit IRC (Read error: Connection reset by peer) 2011-11-02T12:35:24 *** antgreen has joined #rtems 2011-11-02T14:39:10 *** DrJoel has joined #rtems 2011-11-02T14:39:10 *** ChanServ sets mode: +o DrJoel 2011-11-02T15:07:49 *** pzagor has joined #rtems 2011-11-02T15:08:31 DrJoel, are you there ? 2011-11-02T15:08:40 yes.. I really am. :) 2011-11-02T15:08:51 don't look behind the curtain of the great Oz though. :) 2011-11-02T15:08:52 hello :) 2011-11-02T15:09:23 i can see you're in great mood to :P 2011-11-02T15:09:49 let me look for those misteriously appearing execution counts :P 2011-11-02T15:10:10 We have one at: 2011-11-02T15:10:10 0xffc17838: 48 00 00 0c b ffc17844 <_Heap_Walk+0x90> 2011-11-02T15:10:32 no branching point there just call on inline function 2011-11-02T15:10:58 this line has been executed once ant the next one twice 2011-11-02T15:11:44 ok, bad example there is jum to this line from smewhere else 2011-11-02T15:13:55 0xffc17a50: 80 7f 00 2c lwz r3,44(r31) | 0x0000029c |*| exec: 2 | taken/not: 0/ 0 0xffc17a54: 4b ff f2 f9 bl ffc16d4c <_Heap_Is_prev_used> | 0x000002a0 |*| exec: 2 | taken/not: 2/ 0 0xffc17a58: 7c 60 1b 78 mr r0,r3 | 0x000002a4 |*| exec: 4 | taken/not: 0/ 0 0xf 2011-11-02T15:14:11 Yuck.. how about a pastebin? 2011-11-02T15:14:43 what's that ? :) 2011-11-02T15:16:31 *** subodh has quit IRC (Ping timeout: 265 seconds) 2011-11-02T15:16:49 http://pastebin.com/ lets you post temporary text for review and preserves formattijng 2011-11-02T15:17:52 *** monstr-rtems has quit IRC (Read error: Operation timed out) 2011-11-02T15:22:34 having trouble? 2011-11-02T15:23:20 didn't know that one :O 2011-11-02T15:23:27 http://pastebin.com/WECpMEwf 2011-11-02T15:23:45 have a look at 21. 0xffc17a58 2011-11-02T15:24:03 its executed 4 times, the previous one only twice 2011-11-02T15:24:28 and from *.gcno i can see that there are no other jumps to that block 2011-11-02T15:26:43 hi drjoel. 2011-11-02T15:26:45 FWIW bl is a subroutine call... 2011-11-02T15:27:04 can you objdump the executable and see if there is another reference to that address? 2011-11-02T15:27:13 hey gedare 2011-11-02T15:27:22 https://picasaweb.google.com/lh/photo/yPe1L5LGhIlFcxo4-brWfxR78oSzFsp_mRBTq0krrT4?feat=directlink 2011-11-02T15:27:29 DrJoel: neo1987___ was looking for you to help figure out that qemu -trace option issue. 2011-11-02T15:27:32 I see you, Chris, and myself 2011-11-02T15:27:49 cool 2011-11-02T15:28:01 I emailed him back. qemu couverture changed the argument name. Depending on which version you get, the command line changes 2011-11-02T15:28:16 hmm.. and amar is behing you 2011-11-02T15:29:15 i figured that was the case. 2011-11-02T15:30:06 pzagor: alexander mentioned something that the in_asm traces only included when a translation block needed to be translated to native operations. If the couverture traces suffer the same characteristic, then we can't do much. 2011-11-02T15:30:28 Except give them an example which shows the trace is wrong. 2011-11-02T15:30:45 i'm fighting with a tlb. and losing 2011-11-02T15:31:49 be light on your feet and don't let it land a shot to your head. :) 2011-11-02T15:32:05 might be too late for that one :) 2011-11-02T15:33:02 I don't know if you overheard but Tobias Burnus (GCC fortran maintainer) and I talked about trying to compile it cross 2011-11-02T15:33:16 i think i caught a bit of that conversation 2011-11-02T15:33:27 gedere: I have no ide what is your problem, but if it is couverture cuemu not accepting -trace opion then you should use "--exec-trace" 2011-11-02T15:33:49 pzagor: thanks, someone else is actually having the problem, but that is good to know 2011-11-02T15:33:53 Well it builds for rtems on x86, m68k, mips and powerpc.. 2011-11-02T15:33:56 my problems are quite different 2011-11-02T15:34:18 got some fortran hello world running? 2011-11-02T15:35:52 not yet. I wanted to see all the targets cross build first. But shouldn't be hard after that.. then we are just awaiting merge of D 2011-11-02T15:46:33 pzagor: still there? 2011-11-02T15:46:41 yes 2011-11-02T15:46:55 trying to get hat objdump for you 2011-11-02T15:48:05 ok.. I am really suspicious that the traces have gaps like Alexander said would be in the "in_asm" debug traces. 2011-11-02T15:49:51 what exacly is an in_asm trace ? 2011-11-02T15:53:40 qemu has debug log file options. in_asm logs the instructions as they are translated. I always thought it was "as executed" but you can execute a block multiple times but only translate it once. They get flushed 2011-11-02T15:55:36 ok... 2011-11-02T15:55:50 * gedare thinks his console driver might be b0rk 2011-11-02T15:56:16 so if this is in fact the case and we have the same gaps in qemu traces, can they even fix it in couverture qemu ? 2011-11-02T15:58:08 Well their entire research project is founded on having accurate input. It would be funny to bust them on it. :) 2011-11-02T15:58:20 You would deserve a gold star. LOL 2011-11-02T15:58:48 I hope they can fix it. We would have to give them a good test case and verify it has gaps. 2011-11-02T15:59:17 May have to reproduce on 386. I don't know which targets they consider critical. I bet sparc/leon2 is one but I have never personally run qemu for that target. 2011-11-02T16:00:03 Any idea how inaccurate this makes the data? We still have "true/false" correct for each instruction. So coverage itself is correct. Perforance counts are whack though 2011-11-02T16:02:13 hmmm in my tool im using only taken / not taken data, because this is how gcov works 2011-11-02T16:02:48 i have a graph in *.gcno which stores all possible transitions between code blocks 2011-11-02T16:03:00 and when i merge this data there are mismatches 2011-11-02T16:03:37 'll do some more research on code optimization, mayby try to compile rtems without any 2011-11-02T16:04:45 i also tried to manually produce gcov output for only one function takig into account only "executed" counters, but that doesn't look right either 2011-11-02T16:05:11 one thing i haven't tried yet is this xcov tool 2011-11-02T16:05:15 If it still produces results gcov can process, then let's focus on getting gcov reports and seeing if this is related to it being a translation block trace not a 100% instruction trace. If so, then the burden for fixing it falls to them. You would just need to provide a good test case, instructions for running it, and seeing how trace is wrong 2011-11-02T16:06:14 Personally I bet you are doing more consistency analysis. I bet the traces are not really execution traces even though they really look like it. :) 2011-11-02T16:06:23 I didn't know that until mentor summit 2011-11-02T16:06:31 their work is focused on Ada... 2011-11-02T16:08:29 hmm well so let me check those things i talked about, and if there is really a problem in couverture I'll try to fabricate a good test case for them 2011-11-02T16:14:18 is it time to merge your changes and try to produce gcov reports as part of report package? 2011-11-02T16:14:34 even with potential issues? As long as we can turn them off. :) 2011-11-02T16:15:51 ok, if we need to do that let me prepare mergable version tomorrow 2011-11-02T16:16:23 i'll add some code for turning it off 2011-11-02T16:17:08 Sooo. when I turn on protection and start mucking with mapped pages to the heap, printf code breaks in bsp-specific parts. oops! 2011-11-02T16:17:34 but otherwise I believe I have a rudimentary protection framework in place 2011-11-02T16:17:38 for sparc64 ;) 2011-11-02T16:18:09 would that be ok? It's getting late here in Poland ;) 2011-11-02T16:18:25 ping drjoel ^ 2011-11-02T16:18:28 gotta get his attention sometimes 2011-11-02T16:18:49 :) 2011-11-02T16:18:50 pzagor I'm sure it is fine to wait til tomorrow to merge code 2011-11-02T16:19:07 or rather to prepare code 2011-11-02T16:19:38 tommorow somehov always seems more appealing for merging the code :P 2011-11-02T16:19:49 whew... my "stress test" still works too. 2011-11-02T16:20:16 good thing I resolved this. no more budget to look at this stuff for a few weeks 2011-11-02T16:21:37 good, Murphys laws are not applying to you then :) 2011-11-02T16:22:38 somewhat. I didn't actually make progress since about Monday. I just decided that the solution is to ignore the problem. 2011-11-02T16:23:59 pzagor: it is fine to wait until tomorrow. sorry.. trackign down breakage in gcc head versus 4.6. :( 2011-11-02T16:24:53 Ok, you both have a great evening then! 2011-11-02T16:25:00 gedare: protection is good but as discussed on list, it breaks classic threads memory model if you apply it too tightly. 2011-11-02T16:25:03 *** pzagor has quit IRC (Quit: Page closed) 2011-11-02T16:25:04 pzagor: head to bed. :) 2011-11-02T16:25:45 DrJoel: I'm aware of the problems. This work might not become mergeable, but since myself and two others at least are looking at it I think there is some interest in finding a workable (configurable) solution. 2011-11-02T16:26:15 I've been meaning to do this for awhile for a research project I'm working on anyways, so that is my use case 2011-11-02T16:26:41 I think the mmu support is good.. tightening it down until you can't share stack memory between tasks will likely break stuff. :) 2011-11-02T16:27:23 maybe... i'm not convinced tasks are supposed to share things on their stacks anyways 2011-11-02T16:27:36 unless you can point me to a valid use case it seems wrong 2011-11-02T16:27:54 granted i'm sure it is done using message queues to pass pointers 2011-11-02T16:28:06 but that is at the user/application level 2011-11-02T16:28:34 i would be surprised to find anything that is fundamentally broken in the cpukit if we applied stack isolation 2011-11-02T16:29:17 as long as only user code is broken then that is fine---they just wouldn't turn on protection 2011-11-02T16:29:59 fwiw i'm not proposing mandatory protection of thread stacks. I don't think anyone is. 2011-11-02T16:35:31 looking for what open group says... 2011-11-02T16:36:29 This defines interfaces and functionality to support multiple flows of control, called threads, within a process. 2011-11-02T16:37:09 address space 2011-11-02T16:37:09 The memory locations that can be referenced by a process or the threads of a process. 2011-11-02T16:37:53 that's the definition of address space.. and now for process 2011-11-02T16:38:06 process 2011-11-02T16:38:06 An address space with one or more threads executing within that address space, and the required system resources for those threads. 2011-11-02T16:38:06 Many of the system resources defined by this specification are shared among all of the threads within a process. These include: the process ID, the parent process ID, process group ID, session membership, real, effective and saved-set user ID, real, effective and saved-set group ID, supplementary group IDs, current working directory, root directory, file mode creation mask and file descriptors. 2011-11-02T16:38:51 thread 2011-11-02T16:38:51 A single flow of control within a process. Each thread has its own thread ID, scheduling priority and policy, errno value, thread-specific key/value bindings, and the required system resources to support a flow of control. Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc(), directly addressable storage obtained through implementation-supplied functions and automatic variabl 2011-11-02T16:38:51 es, are accessible to all threads in the same process. 2011-11-02T16:39:34 mmmm, automatic variables is the key there 2011-11-02T16:39:42 I think that says it.... "Anything whose address may be determined by a thread....are accessible to all threads in the same process" 2011-11-02T16:39:42 nothing else is surprising to me. 2011-11-02T16:39:47 yeah 2011-11-02T16:40:08 if you can put an & on it, it is visible to all threads.. that's pretty clear to me. 2011-11-02T16:40:40 http://pubs.opengroup.org/onlinepubs/007908799/xbd/glossary.html for the history books and irc log :) 2011-11-02T16:40:54 that's well and good, but it doesn't mean that rtems should NOT support the ability to prevent such behavior 2011-11-02T16:41:08 in case someone wants to do so 2011-11-02T16:41:12 With that said, I believe that having protection of individual thread stacks is good as a user option. It sure will take a set of instructions and warnings. :) 2011-11-02T16:41:24 I think that was always the intent. 2011-11-02T16:41:43 But good that the standards provides the permissive use case 2011-11-02T16:41:58 Someone asked if protecting thread stacks was OK within posix. I think we answered that one. It is not pure posix. But it is a good thing from a safety viewpoint 2011-11-02T16:42:30 correct.. we cannot implement this in the posix layer 2011-11-02T16:42:34 afict 2011-11-02T16:42:43 No more of an issue than lowering the number of priorities below the minimum... 2011-11-02T16:43:10 true. 2011-11-02T16:43:30 Well POSIX isn't going to have an API to do this. I think it means that arbitrary POSIX compliant code may not work in this environment and it is to be expected. But if you design with this restriction, you can use POSIX APIs. As long as our implementation is OK with this restriction 2011-11-02T16:44:02 right 2011-11-02T16:45:26 but for now I just need a hacked together solution to get rolling 2011-11-02T16:45:35 which i hope i'm close to 2011-11-02T16:45:42 that's certainly the first goal. :) 2011-11-02T16:46:50 We need to ask Peter D about the Seacoast Chiller he mentions on his website. :) 2011-11-02T16:46:58 HD worked on a microprocessor controlled version of Seacoast’s Chiller, 2011-11-02T16:46:59 a device designed to provide neuroprotection by chilling the surface of the brain in settings such after an operation or following brain trauma. The device is controlled by an embedded PC running the RTEMS real time executive and using Microwindows as the display interface. The multi-threaded software is flash based and written in C++ and C. 2011-11-02T16:46:59 We worked with Seacoast in designing the overall system for medical safety and selected the software environment. 2011-11-02T16:47:39 nce. 2011-11-02T16:49:39 I have a nurse friend who reps something like this but it also handles oxygenation. I need to hit Peter up for a reference. i can't find this device online.. only a patent with Dan Sachs name on it.. I think he writes a column for Embedded Systems Programming.. very small world 2011-11-02T16:49:47 time for me to head home.. 2011-11-02T16:49:48 night 2011-11-02T16:49:51 *** DrJoel has quit IRC (Quit: Leaving) 2011-11-02T17:15:33 *** gedare has quit IRC (Quit: Ex-Chat) 2011-11-02T19:45:34 *** kiwichris has quit IRC (*.net *.split) 2011-11-02T20:25:25 *** xiangfu has joined #rtems 2011-11-02T20:25:44 *** demute has quit IRC (Ping timeout: 244 seconds) 2011-11-02T20:27:53 *** demute has joined #rtems 2011-11-02T21:33:47 *** demute has quit IRC (Ping timeout: 276 seconds) 2011-11-02T21:41:03 *** demute has joined #rtems 2011-11-02T23:45:52 *** antgreen has quit IRC (Ping timeout: 256 seconds) 2011-11-03T01:18:48 *** monstr-rtems has joined #rtems 2011-11-03T01:47:53 *** kiwichris has joined #rtems 2011-11-03T02:06:21 *** arvind_khadri has joined #rtems 2011-11-03T02:06:21 *** arvind_khadri has joined #rtems 2011-11-03T03:14:01 *** arvind_khadri has quit IRC (Ping timeout: 258 seconds) 2011-11-03T04:31:42 *** xiangfu has quit IRC (Ping timeout: 260 seconds) 2011-11-03T04:45:21 *** arvind_khadri has joined #rtems 2011-11-03T04:45:32 *** arvind_khadri has joined #rtems 2011-11-03T05:05:35 *** lcpfnvcy has quit IRC (Ping timeout: 248 seconds) 2011-11-03T05:07:16 *** methril_work has joined #rtems 2011-11-03T06:59:46 *** lcpfnvcy has joined #rtems 2011-11-03T07:26:44 *** xiangfu has joined #rtems 2011-11-03T08:09:14 *** xiangfu has quit IRC (Ping timeout: 260 seconds) 2011-11-03T08:22:45 *** xiangfu has joined #rtems 2011-11-03T08:36:29 *** xiangfu has quit IRC (Ping timeout: 240 seconds) 2011-11-03T09:09:34 *** arvind_khadri has quit IRC (Read error: Operation timed out) 2011-11-03T09:15:24 *** xiangfu has joined #rtems 2011-11-03T09:23:20 *** arvind_khadri has joined #rtems 2011-11-03T09:32:29 *** xiangfu has quit IRC (Ping timeout: 240 seconds) 2011-11-03T09:34:55 *** antgreen has joined #rtems 2011-11-03T10:51:32 *** methril_work has quit IRC (Read error: Connection reset by peer) 2011-11-03T10:52:27 *** arvind_khadri has quit IRC (Ping timeout: 258 seconds) 2011-11-03T10:55:17 *** methril_work has joined #rtems 2011-11-03T10:56:26 *** DrJoel has joined #rtems 2011-11-03T10:56:26 *** ChanServ sets mode: +o DrJoel 2011-11-03T12:20:53 *** methril_work has quit IRC (Ping timeout: 240 seconds) 2011-11-03T12:34:23 *** methril_work has joined #rtems 2011-11-03T12:51:55 *** arvind_khadri has joined #rtems 2011-11-03T12:51:55 *** arvind_khadri has joined #rtems 2011-11-03T13:58:53 *** antgreen has quit IRC (Ping timeout: 240 seconds) 2011-11-03T15:57:23 *** antgreen has joined #rtems 2011-11-03T16:26:52 *** DrJoel has quit IRC (Quit: Leaving) 2011-11-03T16:50:24 *** gedare has joined #rtems 2011-11-03T16:59:42 *** methril has joined #rtems 2011-11-03T16:59:50 *** monstr-rtems has quit IRC (Quit: Leaving) 2011-11-03T17:08:19 *** gedare has quit IRC (Quit: Ex-Chat) 2011-11-03T18:00:55 *** xiangfu has joined #rtems 2011-11-03T19:03:50 *** xiangfu has quit IRC (Read error: Connection reset by peer) 2011-11-03T19:09:54 *** xiangfu has joined #rtems 2011-11-03T20:06:37 *** neo1987___ has joined #rtems 2011-11-03T20:06:47 *** neo1987___ has left #rtems 2011-11-03T21:44:18 *** xiangfu has quit IRC (Ping timeout: 252 seconds) 2011-11-03T22:17:07 *** arvind_khadri has quit IRC (Ping timeout: 258 seconds) 2011-11-03T22:30:45 *** arvind_khadri has joined #rtems 2011-11-04T00:27:05 *** arvind_khadri has quit IRC (Ping timeout: 252 seconds) 2011-11-04T00:27:38 *** antgreen has quit IRC (Ping timeout: 260 seconds) 2011-11-04T01:47:27 *** arvind_khadri