2013-08-05T00:47:18 *** freenix has joined #rtems 2013-08-05T00:52:51 *** the9a3eedi has joined #rtems 2013-08-05T01:27:51 *** arvind_khadri has joined #rtems 2013-08-05T02:06:15 *** the9a3eedi has quit IRC (Read error: Connection reset by peer) 2013-08-05T02:06:33 *** the9a3eedi has joined #rtems 2013-08-05T02:23:02 *** sebhub has joined #rtems 2013-08-05T02:24:17 good morning 2013-08-05T03:03:49 *** MegaAlex|away has quit IRC (Ping timeout: 248 seconds) 2013-08-05T03:04:34 *** MegaAlex|away has joined #rtems 2013-08-05T03:38:56 *** tictoc has joined #rtems 2013-08-05T04:06:02 *** arvind_khadri has quit IRC (Ping timeout: 256 seconds) 2013-08-05T04:22:00 *** arvind_khadri has joined #rtems 2013-08-05T04:40:58 *** sebhub has quit IRC (Ping timeout: 276 seconds) 2013-08-05T05:21:21 *** phipse has joined #rtems 2013-08-05T05:50:18 *** the9a3eedi has quit IRC (Ping timeout: 264 seconds) 2013-08-05T06:28:18 *** arvind_khadri has quit IRC (Read error: Connection reset by peer) 2013-08-05T06:44:09 *** arvind_khadri has joined #rtems 2013-08-05T06:49:52 *** sebhub has joined #rtems 2013-08-05T07:12:19 *** hiddenpearls has joined #rtems 2013-08-05T07:13:21 *** hiddenpearls has quit IRC (Client Quit) 2013-08-05T08:04:15 *** hiddenpearls has joined #rtems 2013-08-05T08:06:07 *** hiddenpearls1 has joined #rtems 2013-08-05T08:08:53 *** hiddenpearls has quit IRC (Read error: Connection reset by peer) 2013-08-05T08:12:09 *** hiddenpearls1 has quit IRC (Ping timeout: 264 seconds) 2013-08-05T08:15:06 *** hiddenpearls has joined #rtems 2013-08-05T08:20:47 *** hiddenpearls has quit IRC (Quit: Leaving.) 2013-08-05T08:22:10 Hi. When I create a POSIX timer in RTEMS, why is the emitted signal when the timer expires only visible in the same thread and not to all threads? 2013-08-05T08:22:17 Regards 2013-08-05T08:23:18 *** hiddenpearls has joined #rtems 2013-08-05T08:28:40 which functions do you use? 2013-08-05T08:29:54 timer_create and sigwait 2013-08-05T08:33:57 *** hiddenpearls has quit IRC (Ping timeout: 248 seconds) 2013-08-05T08:34:01 i think the current implementation in rtems is a posix standard violation 2013-08-05T08:34:14 : p 2013-08-05T08:34:36 i would ask on the mailing list or open a bug 2013-08-05T08:34:45 ok 2013-08-05T08:36:37 see also _POSIX_Timer_TSR() why this signal is only sent to the particular thread 2013-08-05T08:36:50 so its clearly a bug/feature 2013-08-05T08:37:58 thanks 2013-08-05T08:39:17 can you tell me without looking it up if all signals that address processes are only relayed to the emitting thread or is it just a bug in the timer implementation? 2013-08-05T08:39:32 wait I will look at _POSIX_Timer_TSR() myself... 2013-08-05T08:39:45 only the timer is affected 2013-08-05T08:40:02 this function defines the actions when the timer expires 2013-08-05T08:41:04 great thanks 2013-08-05T09:01:37 does this go to the user or to the development mailing list? 2013-08-05T09:01:56 i would put it on the user list 2013-08-05T09:02:01 ok 2013-08-05T09:11:26 *** weiY has joined #rtems 2013-08-05T09:34:47 *** freenix has quit IRC (Remote host closed the connection) 2013-08-05T10:18:45 *** arvind_khadri has quit IRC (Ping timeout: 264 seconds) 2013-08-05T10:34:39 *** arvind_khadri has joined #rtems 2013-08-05T10:42:18 *** tictoc has quit IRC (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) 2013-08-05T10:53:41 *** weiY has quit IRC (Quit: Linkinus - http://linkinus.com) 2013-08-05T10:53:44 *** sebhub has quit IRC (Remote host closed the connection) 2013-08-05T11:12:33 *** antgreen has joined #rtems 2013-08-05T11:17:44 *** arvind_khadri has quit IRC (Remote host closed the connection) 2013-08-05T11:36:15 *** antgreen has quit IRC (Ping timeout: 245 seconds) 2013-08-05T12:04:32 *** MegaAlex|away is now known as MegaAlex 2013-08-05T19:37:35 *** MegaAlex is now known as MegaAlex|away 2013-08-05T19:38:36 *** kiwichris has joined #rtems 2013-08-05T23:00:07 *** kiwichris_ has joined #rtems 2013-08-05T23:02:07 *** kiwichris has quit IRC (Ping timeout: 268 seconds) 2013-08-06T00:47:03 *** sebhub has joined #rtems 2013-08-06T00:47:09 good morning 2013-08-06T01:10:39 *** the9a3eedi has joined #rtems 2013-08-06T01:32:22 *** the9a3eedi has quit IRC (Read error: Connection reset by peer) 2013-08-06T01:33:08 *** the9a3eedi has joined #rtems 2013-08-06T01:35:30 *** arvind_khadri has joined #rtems 2013-08-06T01:35:52 kiwichris_, wanted to mention that I solved the "unresolved references" problem. Turns out it was trying to add static symbols to the symbol table :| due to an incorrect nm command 2013-08-06T01:36:21 thanks for your help 2013-08-06T01:36:54 the9a3eedi, you may want to try https://github.com/MrVan 2013-08-06T01:37:17 this is a GSoC students work. The gdb has the start of debugging support via gdb 2013-08-06T01:41:19 *** the9a3eedi has left #rtems ("Leaving") 2013-08-06T01:41:26 *** the9a3eedi has joined #rtems 2013-08-06T01:41:49 Sounds interesting ... I'll take a look 2013-08-06T01:45:58 It is work in progress 2013-08-06T01:46:16 The rtl and rtl-host repos should be ok 2013-08-06T01:46:45 The gdb is interesting and once done will provide debugging of loaded code 2013-08-06T02:28:23 *** the9a3eedi has quit IRC (Ping timeout: 240 seconds) 2013-08-06T03:01:08 *** tictoc has joined #rtems 2013-08-06T03:25:21 *** freenix has joined #rtems 2013-08-06T03:37:06 *** the9a3eedi has joined #rtems 2013-08-06T03:52:59 *** arvind_khadri has quit IRC (Read error: Connection reset by peer) 2013-08-06T04:06:01 *** arvind_khadri has joined #rtems 2013-08-06T04:07:08 *** arvind_khadri has joined #rtems 2013-08-06T04:08:21 *** arvind_khadri has joined #rtems 2013-08-06T04:33:37 *** MegaAlex|away is now known as MegaAlex 2013-08-06T04:45:30 *** the9a3eedi has quit IRC (Read error: Connection reset by peer) 2013-08-06T04:52:13 freenix, hi 2013-08-06T04:52:30 *** arvind_khadri has quit IRC (Ping timeout: 245 seconds) 2013-08-06T04:53:16 sebhub, hi 2013-08-06T04:53:27 Is task deletion going to be supported ? 2013-08-06T04:54:07 this is a major task 2013-08-06T04:54:32 Can a task be deleted ? 2013-08-06T04:54:41 ie a POSIX thread ? 2013-08-06T04:55:32 on smp thread delete does not work at the moment regardless of the api 2013-08-06T04:55:59 Ok. RTEMS 4.11 cannot be released until this is fixed. It is a major blocker 2013-08-06T04:56:25 the single processor version can still delete threads 2013-08-06T04:56:38 only the smp configuration has this problem 2013-08-06T04:56:41 My understanding is SMP is for 4.11 2013-08-06T04:56:59 hm, this will delay 4.11 for a year i guess 2013-08-06T04:57:08 It is that big ? 2013-08-06T04:57:33 not the delete alone, but there are other issues 2013-08-06T04:57:59 currently we have smp with some unsupported features 2013-08-06T04:58:16 What are they ? 2013-08-06T04:59:20 thread deletion, C++ global constructors, Ada self task, pthread_once, pthread_cleanup, C++ thread local storage 2013-08-06T04:59:54 thread deletion is the major issue 2013-08-06T05:01:08 yes, but there are some steps necessary to get this working 2013-08-06T05:01:21 Are they written up ? 2013-08-06T05:01:28 see my thread life cycle post on rtems-devel 2013-08-06T05:01:33 Ok 2013-08-06T05:01:43 I will look again tomorrow 2013-08-06T05:03:28 Just looking, a hint on the subject or date of the email ? 2013-08-06T05:04:45 Found it 2013-08-06T05:04:46 *** arvind_khadri has joined #rtems 2013-08-06T05:05:05 i am away for the meal 2013-08-06T05:10:07 Ok. Some parts of this have been known about for a long time. 2013-08-06T05:18:30 sebhub: the stuff that doesn't work with SMP does it give a clean error or just undefined behavour? 2013-08-06T05:19:26 kiwichris_, sebhub: got the P1020 Freescale board the smp stuff is running on, and planning to get Erlang with SMP enabled running on it 2013-08-06T05:20:06 hope Erlang doesn't want to do any of the unsupported features 2013-08-06T05:26:58 *** sebhub has quit IRC (Ping timeout: 256 seconds) 2013-08-06T05:29:01 *** sebhub has joined #rtems 2013-08-06T05:29:01 you get an error return or fatal error 2013-08-06T05:29:14 you get an error return or fatal error 2013-08-06T05:34:50 *** arvind_khadri has quit IRC (Read error: Connection reset by peer) 2013-08-06T05:35:58 *** arvind_khadri has joined #rtems 2013-08-06T06:15:08 hi, kiwichris_ 2013-08-06T06:15:18 I was away just now. 2013-08-06T07:17:08 sebhub: hope Erlang VM does allways check its error returns 2013-08-06T08:59:10 *** arvind_khadri has quit IRC (Ping timeout: 246 seconds) 2013-08-06T09:05:37 *** freenix has quit IRC (Quit: Leaving) 2013-08-06T09:11:18 *** arvind_khadri has joined #rtems 2013-08-06T09:12:02 *** arvind_khadri has quit IRC (Max SendQ exceeded) 2013-08-06T09:14:06 *** sebhub has quit IRC (Remote host closed the connection) 2013-08-06T09:19:44 *** weiY has joined #rtems 2013-08-06T09:28:39 *** arvind_khadri has joined #rtems 2013-08-06T11:42:21 *** tictoc has quit IRC (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) 2013-08-06T12:18:35 *** weiY has quit IRC (Ping timeout: 260 seconds) 2013-08-06T13:07:30 *** peerst has quit IRC (Quit: peerst) 2013-08-06T14:28:21 *** peerst has joined #rtems 2013-08-06T15:01:35 *** antgreen has joined #rtems 2013-08-06T16:26:57 *** kiwichris_ has quit IRC (Quit: This computer has gone to sleep) 2013-08-06T16:27:38 *** kiwichris has joined #rtems 2013-08-06T19:11:40 *** MegaAlex is now known as MegaAlex|away 2013-08-06T20:20:00 *** freenix has joined #rtems 2013-08-06T20:35:11 hi,kiwichris 2013-08-06T22:36:26 *** arvind_khadri has joined #rtems 2013-08-07T00:04:29 *** monstr__ has joined #rtems 2013-08-07T00:30:31 *** arvind_khadri has quit IRC (Read error: Connection reset by peer) 2013-08-07T00:41:12 *** sebhub has joined #rtems 2013-08-07T00:41:44 good morning 2013-08-07T00:47:52 *** arvind_khadri has joined #rtems 2013-08-07T00:58:50 sebhub, hi 2013-08-07T01:04:28 *** keon has joined #rtems 2013-08-07T01:06:10 *** keon has left #rtems 2013-08-07T01:06:55 hi chris 2013-08-07T01:47:33 *** MegaAlex|away has quit IRC (Ping timeout: 264 seconds) 2013-08-07T01:56:37 *** MegaAlex|away has joined #rtems 2013-08-07T01:59:55 *** monstr__ has quit IRC (Read error: Connection reset by peer) 2013-08-07T02:01:56 *** monstr has joined #rtems 2013-08-07T04:31:26 *** MegaAlex|away is now known as MegaAlex 2013-08-07T04:37:54 *** tictoc has joined #rtems 2013-08-07T07:17:45 hi,kiwichris 2013-08-07T08:04:57 *** monstr has quit IRC (Ping timeout: 264 seconds) 2013-08-07T08:42:32 is it allowed to release a semaphore from a thread other than the one that locked it, or does this produce some kind of undefined behaviour? 2013-08-07T08:43:09 this depends on the semaphore type 2013-08-07T08:43:28 do you use the posix api? 2013-08-07T08:43:30 counting semaphore 2013-08-07T08:43:37 this should work 2013-08-07T08:43:43 well yes, but this was more of a general concept questions 2013-08-07T08:44:03 for mutex semaphores this is not correct 2013-08-07T08:44:12 they have an owner 2013-08-07T08:44:44 yes I know, I wasn't sure if something like that existed for semaphores too 2013-08-07T08:45:08 thanks! 2013-08-07T09:16:36 *** sebhub has quit IRC (Remote host closed the connection) 2013-08-07T09:37:15 *** freenix has quit IRC (Quit: Leaving) 2013-08-07T09:43:07 *** tictoc has quit IRC (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) 2013-08-07T10:59:44 *** arvind_khadri has quit IRC (Remote host closed the connection) 2013-08-07T11:26:19 *** antgreen has quit IRC (Ping timeout: 264 seconds) 2013-08-07T11:32:48 *** MegaAlex is now known as MegaAlex|away 2013-08-07T12:43:13 *** antgreen has joined #rtems 2013-08-07T13:40:54 *** antgreen has quit IRC (Ping timeout: 264 seconds) 2013-08-07T14:14:30 *** monstr has joined #rtems 2013-08-07T18:12:38 *** antgreen has joined #rtems 2013-08-07T18:36:36 *** antgreen has quit IRC (Quit: Leaving) 2013-08-07T18:38:39 *** antgreen has joined #rtems 2013-08-07T19:44:59 *** freenix has joined #rtems 2013-08-07T22:05:02 *** freenix has quit IRC (Ping timeout: 240 seconds) 2013-08-07T22:05:29 *** freenix has joined #rtems 2013-08-07T22:09:50 *** antgreen has quit IRC (Ping timeout: 240 seconds) 2013-08-07T22:24:25 *** antgreen has joined #rtems 2013-08-07T23:32:55 *** antgreen has quit IRC (Ping timeout: 264 seconds) 2013-08-07T23:39:29 *** monstr__ has joined #rtems 2013-08-08T01:02:00 *** sebhub has joined #rtems 2013-08-08T01:02:29 good morning 2013-08-08T01:03:34 *** kiwichris has quit IRC (Quit: This computer has gone to sleep) 2013-08-08T01:18:02 *** kiwichris has joined #rtems 2013-08-08T01:20:05 sebhub, hi 2013-08-08T01:29:19 sebhub, I am working on a fix for C++ 2013-08-08T01:47:57 why did you add to keyimpl.h? 2013-08-08T01:48:32 It did not build 2013-08-08T01:48:42 It references Thread_Control 2013-08-08T01:49:32 back soon 2013-08-08T01:49:47 *** kiwichris has quit IRC (Quit: This computer has gone to sleep) 2013-08-08T02:10:12 *** kiwichris has joined #rtems 2013-08-08T02:45:22 *** sebhub has quit IRC (Read error: Operation timed out) 2013-08-08T02:46:12 *** sebhub has joined #rtems 2013-08-08T02:50:02 sebhub, is "#if RTEMS_SMP" ok ? 2013-08-08T02:50:25 or is it "#if defined( RTEMS_SMP )" ? 2013-08-08T02:50:49 i used #if defined( RTEMS_SMP ) since this is what was originally used 2013-08-08T02:59:09 Hmmm shame, #if RTEMS_SMP is safer 2013-08-08T02:59:38 yes, but this defined( X ) is used all over the place in RTEMS 2013-08-08T03:00:02 If we could have POSIX built at 0 cost to users who do not use it we could switch gcc to use the POSIX thread model 2013-08-08T03:00:08 i don't care, but it should be consistent 2013-08-08T03:01:02 I do. -DRTEMS_SMP -DRTEMS_SMP=0 and -DRTEMS_SMP=1 all mean the same thing 2013-08-08T03:01:17 It is the old BSP_OPTS issue 2013-08-08T03:01:30 yes, we should use the posix thread model in the long run 2013-08-08T03:01:55 i only say that we should not use #if defined in on file and #f in another for the same symbol 2013-08-08T03:02:01 To do this POSIX needs to a 0 cost to those who do not use it 2013-08-08T03:02:19 Yes this I agree with 2013-08-08T03:02:37 BSP_OPTS is an example where is not true 2013-08-08T03:03:00 yes, its a mess 2013-08-08T03:03:13 I have gthr-posix.h in libcsupport and will use it when RTEMS_SMP is defined 2013-08-08T03:03:29 This is a step to the gcc POSIX thread model 2013-08-08T03:03:31 we have not good coding style guild, this is the source of problems like this 2013-08-08T03:03:58 To get a good guide we will need to code sweeps to clean things up 2013-08-08T03:04:23 I am fighting the preinstall bugs where changes are not picked up and installed 2013-08-08T03:04:28 grr hate it 2013-08-08T03:04:45 Did the keyimpl.h change make sense ? 2013-08-08T03:05:34 yes, the problem didn't show up on my side since I used a different objectimpl.h 2013-08-08T03:06:34 Updated cgit on git.rtem.org and cleaned the cache out. It is all better now 2013-08-08T03:09:39 Do you think restart will be light weight enough to be able to do it ? 2013-08-08T03:10:00 to do what? 2013-08-08T03:10:10 a cancel handler call ? 2013-08-08T03:10:20 in the thread context 2013-08-08T03:10:28 being closed 2013-08-08T03:11:12 did you explain this in your last email? 2013-08-08T03:11:28 i didn't read it yet 2013-08-08T03:12:23 I see 3 options, a "first class" handler hook in the TCP, restart or pushing a call into the context (which could just be restart). 2013-08-08T03:12:31 TCP -> TCB 2013-08-08T03:13:02 There is no way I will use the post switch user extension 2013-08-08T03:13:19 Too much overhead for something that does not happen often 2013-08-08T03:14:44 the only problem with restart i see is the restart of remote threads 2013-08-08T03:15:31 we also need a special restart, we have to preserve the current stack pointer since the cleanup contexts will reside on the thread stack (see my proposed newlib change) 2013-08-08T03:15:54 Yeah ok my 3rd option of pushing a new context on the stack 2013-08-08T03:16:41 *** arvind_khadri has joined #rtems 2013-08-08T03:16:48 So it is a TCB level hook or pushing a new context 2013-08-08T03:17:28 back later 2013-08-08T03:17:39 i think the restart of remote threads needs 1. a post switch hook or 2. some sort of spinning 2013-08-08T03:46:06 *** freenix has quit IRC (Quit: Leaving) 2013-08-08T05:27:05 *** tictoc has joined #rtems 2013-08-08T05:44:08 Hello everyone. I have another issue with the POSIX API. I tried using queued RT signals, however I encountered two issues. First signals are not queued and only one signal is left pending. Second if you send a signal using sigqueue() before a thread waits on it with sigwaitinfo() , the signal is left pending as expected and gets retrieved upon the sigwaitinfo() call, but the transmitted... 2013-08-08T05:44:10 ...value appears to be lost (it is set to zero). Is this an unsupported feature or do I need to set configure RTEMS to get this working properly? 2013-08-08T06:00:01 i cannot say much about this since i use the posix api rarely 2013-08-08T06:00:27 it would be good to have a self contained test case which shows the posix violation 2013-08-08T06:00:39 we can then add it to the rtems test suite and fix it 2013-08-08T06:16:37 sounds good 2013-08-08T06:17:08 regarding your timer problem, i am no sure if this is a bug or feature 2013-08-08T06:17:51 from the posix docs its clear that this timer issues a signal for the process and not a thread 2013-08-08T06:18:43 I would say it doesn't conform to POSIX. But I suspect at least the timer with an interval set to zero is a bug. 2013-08-08T06:18:53 i would ask on the list if posix standard violations are in general a bug which should be fixed 2013-08-08T06:21:01 Yes. If not they should at least be documented. 2013-08-08T06:21:29 from my point of view all the standard violations are bugs 2013-08-08T06:21:48 I think most people will agree 2013-08-08T06:22:29 Regarding the zero interval timer, after the initial expiration the timer resets to some 4k second timeout value. I think POSIX doesn't clearly state that the value should remain at zero, but I suspect that the timer will also emit the signal a second time once the 4k seconds elapse 2013-08-08T06:22:33 this timer issue seems to be there since day one so maybe this is now a feature 2013-08-08T06:22:37 4k on my machine 2013-08-08T06:23:35 so this definitly is a bug (the zero interval timer) 2013-08-08T06:24:17 i am currently very busy with other stuff so i will likely not work on this 2013-08-08T06:24:35 unless one of our customer complais about it ;-) 2013-08-08T06:24:51 I am not currently one of those :p 2013-08-08T06:25:27 Regarding the testsuit, if I have some spare time on the weekend I will write something, but I also have only very little free time atm. 2013-08-08T06:41:46 *** MegaAlex|away has quit IRC (Ping timeout: 276 seconds) 2013-08-08T06:41:46 *** antgreen has joined #rtems 2013-08-08T06:42:55 *** MegaAlex|away has joined #rtems 2013-08-08T06:57:08 *** arvind_k has joined #rtems 2013-08-08T06:59:19 *** arvind_khadri has quit IRC (Ping timeout: 276 seconds) 2013-08-08T07:57:08 *** arvind_k has quit IRC (Read error: Connection reset by peer) 2013-08-08T07:58:48 *** arvind_k has joined #rtems 2013-08-08T08:20:38 *** arvind_k has quit IRC (Ping timeout: 256 seconds) 2013-08-08T08:36:49 *** antgreen has quit IRC (Ping timeout: 276 seconds) 2013-08-08T09:12:09 *** vipulnayyar has joined #rtems 2013-08-08T09:16:09 *** phipse has joined #rtems 2013-08-08T10:00:33 *** vipulnayyar has quit IRC (Quit: Leaving) 2013-08-08T10:21:44 *** monstr__ has quit IRC (Ping timeout: 260 seconds) 2013-08-08T10:34:42 *** sebhub has quit IRC (Remote host closed the connection) 2013-08-08T11:10:56 *** tictoc has quit IRC (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130730113002]) 2013-08-08T11:19:04 *** phipse has quit IRC (Ping timeout: 264 seconds) 2013-08-08T11:31:50 *** antgreen has joined #rtems 2013-08-08T11:55:18 *** antgreen has quit IRC (Ping timeout: 264 seconds) 2013-08-08T13:28:04 *** phipse has joined #rtems 2013-08-08T13:32:52 *** phipse has quit IRC (Ping timeout: 264 seconds) 2013-08-08T13:45:13 *** antgreen has joined #rtems 2013-08-08T15:48:47 *** phipse has joined #rtems 2013-08-08T15:58:40 *** phipse has quit IRC (Ping timeout: 264 seconds) 2013-08-08T17:53:12 *** antgreen has quit IRC (Ping timeout: 276 seconds) 2013-08-08T21:31:51 *** antgreen has joined #rtems 2013-08-08T22:15:44 *** freenix has joined #rtems 2013-08-08T22:26:32 *** freenix has quit IRC (Quit: Leaving) 2013-08-09T00:16:45 *** monstr__ has joined #rtems 2013-08-09T00:41:29 *** sebhub has joined #rtems 2013-08-09T00:41:53 good morning 2013-08-09T00:42:03 sebhub, morning 2013-08-09T00:43:54 sebhub, take a look at this .. https://gist.github.com/kiwichris/6191421/raw/c3b02cda8db625e3edb437fda9227ffc73ec59f5/gistfile1.txt 2013-08-09T00:45:32 If you look you will see an -isystem path that ends with '.../newlib/libc/include' and after a -I that ends with '..../newlib/libc/sys/rtems/include'. 2013-08-09T00:45:55 There is a machne/_types.h in the -isystem path before the RTEMS one 2013-08-09T00:48:45 The general one is being used and not the RTEMS one 2013-08-09T00:52:28 All directories named by -isystem are searched after all directories named by -I, no matter what their order was on the command line. If the same directory is named by both -I and -isystem, the -I option is ignored. GCC provides an informative message when this occurs if -v is used. 2013-08-09T00:52:34 from gcc docs 2013-08-09T00:54:03 Hmm ok I will take a closer look. The POSIX thread model breaks cause _mode_t is not found which is in the RTEMS _types.h 2013-08-09T00:54:09 And thanks 2013-08-09T00:54:57 The RTEMS thread model header in gcc changes the types and this make hooking POSIX difficult 2013-08-09T00:58:45 The path is head of the list so that part is working. 2013-08-09T01:00:55 did you look at the preprocessed file, e.g. -save-temps 2013-08-09T01:03:07 Not yet. Just playing with the headers at the moment. I did an -MM to get the deps list 2013-08-09T01:03:25 The rtems machine/_types.h file is not being included 2013-08-09T01:03:33 Uses a #error to check 2013-08-09T01:05:17 Picking up newlib/libc/include/machine/_types.h 2013-08-09T01:06:40 The path is ../newlib/libc/sys/rtems/include 2013-08-09T01:07:14 however the header is in '../newlib/libc/sys/rtems/machine' 2013-08-09T01:07:35 so the -I should be '-I ..../newlib/libc/sys/rtems' 2013-08-09T01:08:11 However this breaks limits.h which is in ../newlib/libc/sys/rtems/include 2013-08-09T01:08:14 what a mess 2013-08-09T01:10:09 I think this is a bug in our newlib set up. 2013-08-09T01:11:32 oh, this really looks like a mess 2013-08-09T01:13:29 The tools just happen to work rather than work as a result of careful checking and design 2013-08-09T01:13:42 I will look for a simple patch 2013-08-09T01:14:16 The simple patch is 2 -I's to each libc/sys/rtems location 2013-08-09T01:14:57 I wonder is sys and machine should be moved to under include 2013-08-09T01:15:41 At least the thread model change is a 1 line patch 2013-08-09T01:16:38 Have you been playing with SPARC recently ? 2013-08-09T01:18:02 the sis is my normal debug target 2013-08-09T01:21:29 Is there a section in the final executable called '.work' ? 2013-08-09T01:22:53 no 2013-08-09T01:24:41 Ok. 2013-08-09T01:25:28 Peng has debugging with GDB working with dynamic object files as either ELF or in a RAP file however the disas command is failing with a section called .work 2013-08-09T01:25:56 It is nice you can set a break point on code not loaded and it breaks when loaded and executed 2013-08-09T01:25:57 on arm and powerpc you may have this section 2013-08-09T01:26:07 What is it ? 2013-08-09T01:26:25 the area for the workspace and heap 2013-08-09T01:26:35 Why in a special section ? 2013-08-09T01:27:07 see http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base 2013-08-09T01:28:00 Is there a reason for this ? 2013-08-09T01:28:00 this section has no content 2013-08-09T01:28:21 it is used to get the work area dimensions 2013-08-09T01:28:28 Well it does when you load code into it because we have overlapping sections 2013-08-09T01:29:27 It is to hold the bsp_section_work_end etc ? 2013-08-09T01:29:33 yes 2013-08-09T01:29:45 Do they have to be in a section ? 2013-08-09T01:29:56 yes, to use the regions 2013-08-09T01:30:30 Ok and thanks. I will Peng know. We will have to think about this a little more. We may need gdb guru help on this one 2013-08-09T01:30:51 [ 9] .work NOBITS 0010d4e0 040ed8 feeeb20 00 WA 0 0 1 2013-08-09T01:32:17 The symbol look up fails in gdb with the disas command but works with a breakpoint. 2013-08-09T01:32:21 It may be a gdb problem 2013-08-09T01:39:03 Found it 'libgcc/config/t-rtems' 2013-08-09T01:42:29 i like these makefile snippets 2013-08-09T01:43:04 *** tictoc has joined #rtems 2013-08-09T01:43:49 i would rather use _Scheduler_Generic_block than _Thread_Is_executing_or_the_heir 2013-08-09T01:44:11 this _Thread_Is_executing_or_the_heir is only a replacement of || with normal language 2013-08-09T02:05:52 Sure. 2013-08-09T02:06:21 Yes and it does say what the intention is which is important when reviewing the code in 2 years time 2013-08-09T02:19:39 sebhub, looks like the POSIX thread model builds with the updated path 2013-08-09T02:19:50 this is nice 2013-08-09T02:20:27 I will post the patch to the mailing list once I have test the iostream sample 2013-08-09T02:21:13 what do we need from the posix api, is this only keys and the once function? 2013-08-09T02:21:26 There is also mutexes 2013-08-09T02:22:07 From the iosream it looks like once, a mutex and a key 2013-08-09T02:23:16 Using the POSIX thread model which is all contained in gcc source means any changes will be tested and supported rather than breaking our private hack 2013-08-09T02:45:29 The iostream C++ sample works with the POSIX thread model on an SMP Cortex-A9 zc607 2013-08-09T02:45:37 zc706 2013-08-09T02:52:26 i am struggeling with the smp scheduler 2013-08-09T02:52:35 ? 2013-08-09T02:53:18 after some modifications i have a thread executing on two processors 2013-08-09T02:53:53 Same thread ? 2013-08-09T02:54:00 yes 2013-08-09T02:54:31 Genius, must be running twice as fast ;) 2013-08-09T03:08:08 *** MegaAlex|away has quit IRC (Ping timeout: 241 seconds) 2013-08-09T03:09:14 *** MegaAlex|away has joined #rtems 2013-08-09T03:30:06 it was a damn typo 2013-08-09T03:30:38 hehe 2013-08-09T03:32:20 This leaves the self close task, privateenv, then bdbuf (classic condition vars) 2013-08-09T03:34:56 *** phipse has joined #rtems 2013-08-09T03:35:15 restart of remote threads 2013-08-09T03:35:38 the pthread once function is also broken 2013-08-09T03:36:14 Huh ? 2013-08-09T03:36:26 it uses preempt disable 2013-08-09T03:36:31 hah 2013-08-09T03:38:03 that is funny, it calls the class API 2013-08-09T03:38:19 What is the fix ? 2013-08-09T03:40:16 use a mutex 2013-08-09T03:40:39 a mutex for all once functions 2013-08-09T03:40:41 I also think the lock only needs to be held while updating the once data and not while running the init function 2013-08-09T03:40:47 Static allocation ? 2013-08-09T03:41:00 we have the asynchronous cancellation problem in this case again 2013-08-09T03:41:16 no, read the posix docs 2013-08-09T03:41:36 in case the once function returns the init must be done 2013-08-09T03:42:03 Sure but can it be preempted ? 2013-08-09T03:42:58 what you would get with the lock for data only approach is: someone will call the init function once 2013-08-09T03:43:55 http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_once.html 2013-08-09T03:44:02 On return from pthread_once(), it is guaranteed that init_routine() has completed. 2013-08-09T03:44:28 Ah yes I get it 2013-08-09T03:45:42 I am off for the night. This can wait until another day. 2013-08-09T03:46:19 cu 2013-08-09T04:50:58 *** sebhub has quit IRC (Read error: Operation timed out) 2013-08-09T04:51:30 *** sebhub has joined #rtems 2013-08-09T06:19:01 *** MegaAlex|away