2013-10-28T01:51:50 Hi. I've been testing RTL for a while now and I've noticed that while it does load correctly, it takes a lot of time for me. I'm loading a RAP file of size 175KB, with 410 symbols. It takes 23 seconds to load the file on a LEON3. maybe it's just me but it seems quite high. 2013-10-28T01:53:25 out of that 23 seconds, it takes 19 seconds in rtems_rtl_rap_relocate(), so I'm looking there at the moment to see if there's anything that can be improved 2013-10-28T01:54:01 is this amount of time typical for loading a RAP of this size? 2013-10-28T01:59:59 *** monstr_ has joined #rtems 2013-10-28T02:44:16 *** sebhub has joined #rtems 2013-10-28T02:46:39 good morning 2013-10-28T02:56:07 *** MegaAlex|away has quit IRC (Ping timeout: 272 seconds) 2013-10-28T02:56:28 *** sebhub has quit IRC (Ping timeout: 240 seconds) 2013-10-28T02:57:11 *** sebhub has joined #rtems 2013-10-28T03:05:20 *** cafi has joined #rtems 2013-10-28T03:14:32 *** MegaAlex|away has joined #rtems 2013-10-28T03:18:59 *** MegaAlex|away has quit IRC (Ping timeout: 260 seconds) 2013-10-28T03:35:26 mkhoory: no clue why RTL takes so long but this really seems hight to me 2013-10-28T03:36:09 I'm also looking into RTL and 23 seconds would totally mess with my boot time (3 seconds currently) 2013-10-28T03:36:34 kiwichri_: any thoughts on this? 2013-10-28T03:36:43 peerst: perhaps I'm compiling the RAP wrong... anyways I'm trying to load an ELF file just to compare 2013-10-28T03:38:01 by compiling the RAP wrong, I mean maybe I'm building it in a way that loading it would be inefficient, or maybe I'm not using the format correctly. I need to check on this 2013-10-28T03:38:19 don't draw any conclusions yet lol 2013-10-28T03:38:24 relocation shouldnt take so long its normally just a simple add mask thing 2013-10-28T03:46:52 add and mask I meant 2013-10-28T03:46:56 and search 2013-10-28T03:47:27 maybe its the search part some O(n^2) thing going on for largish n 2013-10-28T04:06:51 hmm.. loading the module with ELF format (not RAP) took 9 seconds which is much better, but I'm not sure if it's still as fast as it should be 2013-10-28T04:08:26 *** MegaAlex|away has joined #rtems 2013-10-28T05:44:11 *** sebhub has quit IRC (Read error: Operation timed out) 2013-10-28T05:45:02 *** sebhub has joined #rtems 2013-10-28T05:52:38 *** freenix has joined #rtems 2013-10-28T05:58:06 hi 2013-10-28T05:59:29 has someone tried to use printf on arm rtems4.11? 2013-10-28T06:00:48 yes, what is the problem? 2013-10-28T06:04:56 undefined reference to printf and in my makefile I have included libgcc 2013-10-28T06:05:40 in this case you use completely wrong compiler options 2013-10-28T06:05:42 I guess in this archive it must be no ? 2013-10-28T06:07:13 you can build the bsp with the "--enable-tests=samples" configure option 2013-10-28T06:07:16 the samples show you the right tool chain options 2013-10-28T06:18:14 arm-rtems4.11-gcc-4.8.1 is ok but when I try to link with arm-rtems4.11-ld there i get this issue 2013-10-28T06:19:29 can you please past your linker command line? 2013-10-28T06:25:42 arm-rtems4.11-ld $(LDFLAGS) $(LIBS) -Map $@.map S^ -o S@ 2013-10-28T06:26:22 no, the actual invocation with fully expanded variables 2013-10-28T07:02:51 *** antgreen has quit IRC (Ping timeout: 272 seconds) 2013-10-28T08:21:13 *** antgreen has joined #rtems 2013-10-28T08:31:47 *** MegaAlex|away has quit IRC (Ping timeout: 272 seconds) 2013-10-28T08:33:32 *** MegaAlex|away has joined #rtems 2013-10-28T08:37:33 *** freenix has quit IRC (Quit: Leaving) 2013-10-28T08:44:48 *** vipulnayyar has joined #rtems 2013-10-28T08:45:42 *** vipulnayyar has quit IRC (Client Quit) 2013-10-28T09:56:12 *** S_Somani has joined #rtems 2013-10-28T09:56:20 *** S_Somani has left #rtems 2013-10-28T10:26:17 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2013-10-28T11:10:11 *** antgreen has quit IRC (Ping timeout: 245 seconds) 2013-10-28T11:35:23 *** sebhub has quit IRC (Remote host closed the connection) 2013-10-28T12:07:13 *** monstr_ has quit IRC (Ping timeout: 272 seconds) 2013-10-28T12:29:28 *** edwardk has joined #rtems 2013-10-28T12:32:47 *** edwardk has quit IRC (Read error: Connection reset by peer) 2013-10-28T12:39:22 *** edwardk has joined #rtems 2013-10-28T14:56:59 peerst, no performance profiling has been done on the RTL. 2013-10-28T15:04:28 peerst, also need to consider RAP files are compressed 2013-10-28T15:07:31 *** MegaAlex|away has quit IRC (Ping timeout: 245 seconds) 2013-10-28T15:12:07 *** MegaAlex|away has joined #rtems 2013-10-28T15:19:26 *** MegaAlex|away has quit IRC (Ping timeout: 264 seconds) 2013-10-28T16:11:35 *** edwardk has quit IRC (Ping timeout: 272 seconds) 2013-10-28T18:05:08 kiwichri_: just being curious: is it possible to pre-link some RTL files together statically? 2013-10-28T18:06:37 e.g. my RTEMS application and Erlang runtime as separate RAP files linked together into one image 2013-10-28T18:07:38 which gets later loaded on the target, possibly loading a few smaller so later during runtime (and on demand) 2013-10-28T18:08:53 mkhoory: you read what kiwichris wrote? maybe decompressing is slow on your system, OTOH you report 19 seconds of 23 in relocation functions 2013-10-28T19:03:37 peerst: yeah I was considering that RAP files are compressed, but not by much from what I've seen 2013-10-28T19:13:41 mkhoory, what so you mean "by not much" ? 2013-10-28T19:13:47 what do 2013-10-28T19:14:12 peerst, yes you can do this with the standard linker using the -r optoin 2013-10-28T19:14:29 kiwichri_, I mean it doesn't seem that there's much of a size difference 2013-10-28T19:14:46 Really. That is not what I have seen 2013-10-28T19:17:33 I still need to do some tests, I might be linking wrong 2013-10-28T19:32:31 *** MegaAlex|away has joined #rtems 2013-10-28T21:47:26 *** MegaAlex|away has quit IRC (Ping timeout: 240 seconds) 2013-10-28T21:48:18 *** MegaAlex|away has joined #rtems 2013-10-28T22:07:20 *** MegaAlex|away has quit IRC (Ping timeout: 256 seconds) 2013-10-28T22:08:59 *** MegaAlex|away has joined #rtems 2013-10-28T23:40:27 *** MegaAlex|away has quit IRC (Ping timeout: 264 seconds) 2013-10-28T23:42:14 *** MegaAlex|away has joined #rtems 2013-10-28T23:46:57 *** MegaAlex|away has quit IRC (Ping timeout: 272 seconds) 2013-10-29T02:46:29 *** sebhub has joined #rtems 2013-10-29T02:47:15 good morning 2013-10-29T05:03:03 *** cafi has quit IRC (Ping timeout: 250 seconds) 2013-10-29T05:34:48 *** mkhoory has quit IRC (Ping timeout: 240 seconds) 2013-10-29T05:52:01 *** mkhoory has joined #rtems 2013-10-29T05:57:24 *** mkhoory has quit IRC (Ping timeout: 260 seconds) 2013-10-29T06:04:29 *** mkhoory has joined #rtems 2013-10-29T09:29:38 *** sebhub has quit IRC (Ping timeout: 264 seconds) 2013-10-29T11:58:52 *** antgreen has joined #rtems 2013-10-29T15:45:50 *** antgreen has quit IRC (Ping timeout: 272 seconds) 2013-10-29T20:42:04 *** antgreen has joined #rtems 2013-10-30T02:43:17 *** sebhub has joined #rtems 2013-10-30T02:43:38 good morning 2013-10-30T02:47:27 sebhub: hi 2013-10-30T02:48:33 Looking in gcc-4.8.2/libgcc/config/arm/t-elf I see an option no other arm build has. I wonder if it is still valid. 2013-10-30T02:49:06 HOST_LIBGCC2_CFLAGS += -fno-inline 2013-10-30T02:49:25 Maybe none of the others build this or t-elf is used by everyone. 2013-10-30T02:49:38 this t-elf is obsolete 2013-10-30T02:49:43 arm/t-elf 2013-10-30T02:50:45 what do we use 2013-10-30T02:51:03 hm, i have no arm/t-elf only an arm/t-arm-elf 2013-10-30T02:51:24 oh, wrong directory 2013-10-30T02:52:16 ok, this file is not obsolete 2013-10-30T02:52:24 hmm I have lost the change to 4.8.2. I seem to back on 4.8.1 2013-10-30T02:52:31 I will take a closer look 2013-10-30T02:52:56 should i ask on the gcc list about this HOST_LIBGCC2_CFLAGS += -fno-inline ? 2013-10-30T02:54:04 Do you see it ? 2013-10-30T02:54:20 yes, i looked first in the gcc directory, not libgcc 2013-10-30T02:54:22 I wonder what git blame says 2013-10-30T02:54:26 ah ok 2013-10-30T02:55:27 ro on 2011-11-02 2013-10-30T02:55:34 maybe a good idea to ask 2013-10-30T03:02:36 i have now kqueue working on the new network stack 2013-10-30T03:05:29 Nice 2013-10-30T03:05:50 I cannot find where the include paths are set which is stuffing the microblaze build. 2013-10-30T03:06:09 The header path is wrong in the CFLAGS so the wrong header is picked up 2013-10-30T03:06:18 and so no mode_t 2013-10-30T03:06:27 do you have the "targ-include" directories in your build tree? 2013-10-30T03:07:12 looking ... 2013-10-30T03:08:12 find . -follow -name targ-include 2013-10-30T03:08:15 gives nothing 2013-10-30T03:08:33 what control this ? 2013-10-30T03:09:51 find . -name targ-include 2013-10-30T03:09:52 ./microblaze-rtems4.11/m/newlib/targ-include 2013-10-30T03:09:54 ./microblaze-rtems4.11/m/mh/newlib/targ-include 2013-10-30T03:09:55 ./microblaze-rtems4.11/m/mh/le/newlib/targ-include 2013-10-30T03:09:57 ./microblaze-rtems4.11/m/le/newlib/targ-include 2013-10-30T03:09:58 ./microblaze-rtems4.11/newlib/targ-include 2013-10-30T03:10:00 ./microblaze-rtems4.11/bs/m/newlib/targ-include 2013-10-30T03:10:01 ./microblaze-rtems4.11/bs/m/mh/newlib/targ-include 2013-10-30T03:10:03 ./microblaze-rtems4.11/bs/m/mh/le/newlib/targ-include 2013-10-30T03:10:04 ./microblaze-rtems4.11/bs/m/le/newlib/targ-include 2013-10-30T03:10:06 ./microblaze-rtems4.11/bs/newlib/targ-include 2013-10-30T03:10:07 ./microblaze-rtems4.11/bs/le/newlib/targ-include 2013-10-30T03:10:09 ./microblaze-rtems4.11/le/newlib/targ-include 2013-10-30T03:10:10 it should look like this 2013-10-30T03:10:19 something copies these files from the source tree into the build tree 2013-10-30T03:10:43 i coudn't figure out how it works 2013-10-30T03:10:50 Do you have a log that shows this ? 2013-10-30T03:11:21 yes, 2013-10-30T03:11:29 i can send it to you via email 2013-10-30T03:12:50 Large ? 2013-10-30T03:12:57 rm -rf targ-include stmp-targ-include 2013-10-30T03:12:59 make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CCASFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/scratch/opt/rtems-4.11" "infodir=/ 2013-10-30T03:13:00 scratch/opt/rtems-4.11/share/info" "libdir=/scratch/opt/rtems-4.11/lib64" "prefix=/scratch/opt/rtems-4.11" "tooldir=/scratch/opt/rtems-4.11/arm-rtems4.11" "top_toollibdir=/scratch/opt/rtems-4.11/arm-rtems4.11/lib" "AR=/scratch/opt/rtems-4.11/arm-rtems4.11/bin/ar" "AS=/scratch/git-build/b-gcc-git-arm-rtems4.11/./gcc/as" "CC=/scratch/git-build/b-gcc-git-arm-rtems4.11/./gcc/xgcc -B/scratch/git-build/b-gcc-git-arm-rtems4.11/./gcc/ -nostdinc - 2013-10-30T03:13:02 B/scratch/git-build/b-gcc-git-arm-rtems4.11/arm-rtems4.11/newlib/ -isystem /scratch/git-build/b-gcc-git-arm-rtems4.11/arm-rtems4.11/newlib/targ-include -isystem /home/sh/archive/gcc-git/newlib/libc/include -B/scratch/opt/rtems-4.11/arm-rtems4.11/bin/ -B/scratch/opt/rtems-4.11/arm-rtems4.11/lib/ -isystem /scratch/opt/rtems-4.11/arm-rtems4.11/include -isystem /scratch/opt/rtems-4.11/arm-rtems4.11/sys-include " "LD=/scratch/git-build/b- 2013-10-30T03:13:03 gcc-git-arm-rtems4.11/./gcc/collect-ld" "LIBCFLAGS=-g -O2" "NM=/scratch/git-build/b-gcc-git-arm-rtems4.11/./gcc/nm" "PICFLAG=" "RANLIB=/scratch/opt/rtems-4.11/arm-rtems4.11/bin/ranlib" "DESTDIR=" DO=all multi-do # make 2013-10-30T03:13:05 mkdir targ-include targ-include/sys targ-include/machine targ-include/bits 2013-10-30T03:13:17 thanks 2013-10-30T03:14:17 grep -r 'mkdir targ-include' . 2013-10-30T03:14:19 ./microblaze-rtems4.11/m/newlib/Makefile: mkdir targ-include targ-include/sys targ-include/machine targ-include/bits 2013-10-30T03:14:30 its in the Newlib Makefiles 2013-10-30T03:14:38 ok 2013-10-30T03:16:17 *** sebhub has quit IRC (Remote host closed the connection) 2013-10-30T03:17:04 *** sebhub has joined #rtems 2013-10-30T03:28:44 I noticed something in RTL. If I load a RAP (with dlopen), then try to search the global symbol table with rtems_rtl_global_symbol_find(), I get a NULL returned. 2013-10-30T03:29:12 but if I load an ELF (with dlopen), then try to search the global symbol table for the same symbol in that ELF, I get a bogus pointer 2013-10-30T03:29:52 I realize that I probably shouldn't be searching the global symbol table for a symbol located in a module, but is this considered a bug? it's supposed to return NULL right? 2013-10-30T03:30:16 the RAP and the ELF consist of the same code and I'm trying to get the same symbol in both cases 2013-10-30T08:22:12 *** kiwichri_ has quit IRC (Read error: Connection reset by peer) 2013-10-30T09:52:52 *** bpsmobl has joined #rtems 2013-10-30T09:54:52 *** bpsmobl has quit IRC (Read error: Connection reset by peer) 2013-10-30T11:03:37 *** martanton has joined #rtems 2013-10-30T11:08:16 *** sebhub has quit IRC (Ping timeout: 264 seconds) 2013-10-30T12:03:55 *** martanton has quit IRC (Ping timeout: 240 seconds) 2013-10-30T15:29:18 *** kshurik has joined #rtems 2013-10-30T18:00:31 *** kiwichris has joined #rtems 2013-10-30T18:05:03 mkhoory: thanks for the feedback. Does the dlsym command work as expected ? 2013-10-30T19:03:50 kiwichris, dlsym works as expected yes 2013-10-30T19:04:47 That is good to know 2013-10-30T19:05:39 is there a way to search for a symbol on all loaded modules without having to track them? or do I have to specify the handle like in dlsym? 2013-10-30T19:09:07 The dlsym is the standard interface. Any other interface you find may work but it also may change or go away. 2013-10-30T19:09:40 ok. I guess I'll just keep track of the loaded modules then 2013-10-30T19:09:41 I have not considered providing other means to get at symbols and making some extra calls an RTEMS standard 2013-10-30T19:10:08 It does not mean I am against doing this; I just had not considered it. 2013-10-30T19:54:29 *** kiwichris has quit IRC (Ping timeout: 248 seconds) 2013-10-30T20:48:47 *** kiwichris has joined #rtems 2013-10-31T00:00:15 Hi kiwichris. In rtems_rtl_match_name() is there any reason they're not using strcmp? 2013-10-31T00:00:31 actually the implementation of rtems_rtl_match_name() seems to be incorrect 2013-10-31T00:02:33 *** kiwichris has quit IRC (Ping timeout: 272 seconds) 2013-10-31T00:04:22 hm :/ I guess he didn't read that 2013-10-31T00:11:40 peerst, maybe you can answer it? 2013-10-31T00:14:32 *** kiwichris has joined #rtems 2013-10-31T00:16:15 resending in case you didn't read: 2013-10-31T00:16:20 Hi kiwichris. In rtems_rtl_match_name() is there any reason they're not using strcmp? 2013-10-31T00:16:28 actually the implementation of rtems_rtl_match_name() seems to be incorrect 2013-10-31T00:18:56 mkhoory: which file is that code in ? 2013-10-31T00:19:05 rtl-obj.c 2013-10-31T00:21:18 thanks 2013-10-31T00:22:05 I wanted to submit a patch but I was wondering if I should try to fix the loop, or simply replace the whole thing with strcmp 2013-10-31T00:22:20 I thought maybe there's a reason to use the loop, and not strcmp 2013-10-31T00:26:12 How would you do the same with strcmp ? 2013-10-31T00:26:41 the code delimits on more than \0 2013-10-31T00:27:12 does it need to though? which is what I wanted to ask 2013-10-31T00:27:53 I suspect so. It could be related to the way names are stored in archives 2013-10-31T00:28:35 hmm. I've only tested this with ELFs so I'm not sure about the rest of formats 2013-10-31T00:28:57 It has been a while. How is the code broken ? 2013-10-31T00:29:05 but what's happening with me is that when I load a second ELF (after loading a first one), the function matches the name of the second with the first 2013-10-31T00:29:10 because they both start with '/' 2013-10-31T00:29:36 hmm interesting. 2013-10-31T00:29:40 the names in this case are both full paths to the ELFs 2013-10-31T00:30:39 I'm trying strcmp to see if that fixes it 2013-10-31T00:30:52 you are entering via rtems_rtl_obj_load 2013-10-31T00:30:54 ? 2013-10-31T00:31:15 it's actually entering from dlopen 2013-10-31T00:31:25 which ends up calling that 2013-10-31T00:31:26 hang on. 2013-10-31T00:32:05 yeah 2013-10-31T00:32:11 I mean I'm not calling rtems_rtl_obj_load directly 2013-10-31T00:32:38 sure 2013-10-31T00:32:44 huh.. replacing that with strcmp ends up with me getting a segfault lol 2013-10-31T00:33:21 the only place the match is being made is in the archive find. 2013-10-31T00:33:27 yeah 2013-10-31T00:34:07 why does rtems_rtl_obj_aname_valid return true ? 2013-10-31T00:35:52 I suspect the issue is the setting up the names, ie aname on obj 2013-10-31T00:35:56 in obj 2013-10-31T00:36:51 it's not supposed to set aname? 2013-10-31T00:39:35 I will check; I do not think so unless you have path/file.a:something.o 2013-10-31T00:39:42 in the file name 2013-10-31T00:40:06 You can reference an object file in an archive directly 2013-10-31T00:40:14 and even put @12345 2013-10-31T00:40:39 I see. I'm not use an archive though. I'm simply loading one .o, which I made by linking several objects together with ld -r 2013-10-31T00:40:40 where this is the offset in the archive. A host tool can tell the loader this to speed up searching 2013-10-31T00:40:51 that should be find 2013-10-31T00:40:53 that should be fine 2013-10-31T00:41:07 do you have 2 objs ? 2013-10-31T00:41:22 yes, but they're separate files 2013-10-31T00:41:29 loading one after the other 2013-10-31T00:43:37 I would check rtems_rtl_obj_parse_name 2013-10-31T00:43:47 I suspect this could where things go wrong for you 2013-10-31T00:44:07 what are the filenames ? 2013-10-31T00:45:00 the full path is /ram:0/elf_task.ram 2013-10-31T00:45:23 (I realize the extension isn't standard but that shouldn't be a problem I think) 2013-10-31T00:45:27 ah ok the ':' is break things 2013-10-31T00:45:41 I actually fixed that in a patch recently 2013-10-31T00:45:57 My parser is not strong enough for your case so would like to extend it to make it better ? 2013-10-31T00:46:21 extend it? 2013-10-31T00:46:29 really ? where is the patch ? 2013-10-31T00:47:09 hold on 2013-10-31T00:47:16 Yes rtems_rtl_obj_parse_name needs to be extended to handle your case 2013-10-31T00:48:08 check commit 230f882f3b 2013-10-31T00:48:50 The change is search from the end of the file name for a ':' and if you hit '/' before ':' is is not a colon. 2013-10-31T00:49:00 I will soon. I need to head home; back soon. 2013-10-31T00:49:13 ok 2013-10-31T00:49:14 http://www.rtems.org/pipermail/rtems-devel/2013-September/004494.html 2013-10-31T00:49:16 *** kiwichris has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) 2013-10-31T01:10:46 *** kiwichris has joined #rtems 2013-10-31T01:19:22 kiwichris, actually it's commit 186bc96fa2bd , sorry 2013-10-31T01:34:38 ok, I was a bit confused. It's not actually entering from rtems_rtl_obj_load(), it's entering from rtems_rtl_find_obj(), which goes through the object chain and searches for the filename using rtems_rtl_match_name() 2013-10-31T01:35:32 rtems_rtl_find_obj() is located in rtl.c 2013-10-31T02:03:13 ah ok. 2013-10-31T02:03:35 maybe we need to use add a new function and use that 2013-10-31T02:04:35 or strcmp :P 2013-10-31T02:22:02 nah, a simple strcmp probably won't work. it also needs to check aname before it checks oname 2013-10-31T02:22:39 and aname might be null, so.. 2013-10-31T02:31:37 *** sebhub has joined #rtems 2013-10-31T02:31:46 good morning 2013-10-31T02:42:42 mkhoory: I am sure you will be able to sort it out and send me a patch :) 2013-10-31T02:45:41 kiwichris, yeah, gimme a bit 2013-10-31T03:38:14 *** sebhub has quit IRC (Ping timeout: 240 seconds) 2013-10-31T03:38:42 *** sebhub has joined #rtems 2013-10-31T03:45:44 *** kshurik has quit IRC (Remote host closed the connection) 2013-10-31T05:32:15 *** sebhub has quit IRC (Ping timeout: 246 seconds) 2013-10-31T05:32:25 *** sebhub has joined #rtems 2013-10-31T07:02:06 *** antgreen has quit IRC (Ping timeout: 245 seconds) 2013-10-31T07:05:59 *** sebhub has quit IRC (Ping timeout: 272 seconds) 2013-10-31T07:47:23 *** sebhub has joined #rtems 2013-10-31T09:03:56 *** gedare has joined #rtems 2013-10-31T10:15:00 *** monstr__ has joined #rtems 2013-10-31T10:15:31 ok enough code reviewing i should get some real work done! ha 2013-10-31T10:15:42 thanks, for the reviews! 2013-10-31T10:15:49 yeah.. thanks for the code :) 2013-10-31T10:16:20 the network stack commit count was 147 2013-10-31T10:16:33 but no need to review this 2013-10-31T10:16:52 ok. i don't have enough expertise on that code base anyway 2013-10-31T10:17:00 i should learn it some day. maybe. 2013-10-31T10:17:25 its still a long way 2013-10-31T10:17:54 the SLEEP(8) is a very interesting synchronization api 2013-10-31T10:18:02 and its there for 30 years 2013-10-31T10:18:22 it not real-time though 2013-10-31T10:19:12 got a link to a man page? 2013-10-31T10:19:18 i only find sleep(1) and sleep(3) 2013-10-31T10:19:33 http://www.freebsd.org/cgi/man.cgi?query=sleep&apropos=0&sektion=9&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html 2013-10-31T10:19:48 ah, ok related to the wakeup you sent earlier 2013-10-31T10:19:50 yes this is interesting. 2013-10-31T10:20:39 i'm proposing to do some research on events with some real-time aspects. 2013-10-31T10:20:53 but a lot of my research uses custom hw that is unlikely to see the light of day 2013-10-31T10:21:34 oh, a lot of useless science turned out to be not that useless 2013-10-31T10:21:37 these event mechanisms are everywhere in multicore systems, and there are many problems with latency and scalability 2013-10-31T10:21:57 yeah. it is just hard to tell when doing it! 2013-10-31T10:22:10 all right, gotta focus. later 2013-10-31T10:49:38 *** sebhub has quit IRC (Remote host closed the connection) 2013-10-31T11:50:31 *** antgreen has joined #rtems 2013-10-31T11:55:01 *** monstr__ has quit IRC (Read error: Operation timed out) 2013-10-31T13:25:25 *** kiwichris has quit IRC (*.net *.split) 2013-10-31T14:18:18 *** kiwichris has joined #rtems 2013-10-31T14:48:09 *** gedare has quit IRC (Quit: Leaving) 2013-10-31T23:12:48 *** peerst has quit IRC (Ping timeout: 240 seconds) 2013-10-31T23:15:18 *** peerst has joined #rtems 2013-10-31T23:26:36 *** peerst has quit IRC (Read error: Connection reset by peer) 2013-10-31T23:42:21 *** peerst has joined #rtems 2013-11-01T01:57:43 *** monstr__ has joined #rtems 2013-11-01T03:50:35 *** mkhoory has quit IRC (Read error: Connection reset by peer) 2013-11-01T05:22:04 *** vipulnayyar has joined #rtems 2013-11-01T08:31:18 *** gedare has joined #rtems 2013-11-01T12:38:02 *** monstr__ has quit IRC (Ping timeout: 264 seconds) 2013-11-01T12:49:38 *** jenniferA has joined #rtems 2013-11-01T12:57:08 *** jenniferA has quit IRC (Quit: Page closed) 2013-11-01T13:42:35 *** vipulnayyar has joined #rtems 2013-11-01T13:54:13 *** monstr__ has joined #rtems 2013-11-01T14:22:04 *** monstr__ has quit IRC (Ping timeout: 245 seconds) 2013-11-01T15:39:39 *** gedare has quit IRC (Ping timeout: 260 seconds) 2013-11-02T09:13:32 *** skm has joined #rtems 2013-11-02T09:14:31 Hi everyone. 2013-11-02T09:15:35 Does anyone know if the mingw rtems tools contain the powerpc-rtems4.10-run command or where to find this command. I'm trying to run the hello.exe in psim. 2013-11-02T09:23:55 no idea 2013-11-02T09:24:20 I would expect it would be there 2013-11-02T09:38:48 its not there. Do u know th package which installs this command on mingw? 2013-11-02T10:13:32 *** skm has left #rtems 2013-11-02T13:22:33 *** monstr__ has joined #rtems 2013-11-02T14:55:32 *** sakysharma has joined #rtems 2013-11-02T14:59:37 what is rtems? 2013-11-02T15:20:05 ? 2013-11-02T15:27:50 *** monstr__ has quit IRC (Ping timeout: 240 seconds) 2013-11-02T15:33:17 *** sharmasaky has joined #rtems 2013-11-02T15:37:29 *** sakysharma has quit IRC (Ping timeout: 272 seconds) 2013-11-02T15:42:56 *** sharmasaky is now known as sakysharma 2013-11-02T15:57:31 *** sakysharma has quit IRC (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) 2013-11-03T01:25:35 *** antgreen has quit IRC (Ping timeout: 272 seconds) 2013-11-03T01:26:54 *** antgreen has joined #rtems 2013-11-03T12:23:38 *** guerby has quit IRC (Ping timeout: 264 seconds) 2013-11-03T12:24:38 *** guerby has joined #rtems 2013-11-03T18:15:50 *** mkhoory has joined #rtems 2013-11-03T20:01:33 kiwichris, patch submitted :) 2013-11-03T20:03:55 If there are any comments let me know. It may or may not be the best approach to fixing the bug 2013-11-03T20:49:00 *** arvind_khadri has joined #rtems