From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2078 invoked by alias); 31 Mar 2005 06:30:44 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 2001 invoked from network); 31 Mar 2005 06:30:36 -0000 Received: from unknown (HELO hotmail.com) (64.4.16.67) by sourceware.org with SMTP; 31 Mar 2005 06:30:36 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Mar 2005 22:30:35 -0800 Message-ID: Received: from 192.114.107.4 by by22fd.bay22.hotmail.msn.com with HTTP; Thu, 31 Mar 2005 06:30:35 GMT X-Originating-Email: [moris_dong@hotmail.com] X-Sender: moris_dong@hotmail.com In-Reply-To: From: "moris dong" To: fche@redhat.com, sid@sources.redhat.com Bcc: Subject: Re: SMP board : Bug in SID or configuration file ? Date: Thu, 31 Mar 2005 06:30:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 31 Mar 2005 06:30:35.0400 (UTC) FILETIME=[257C8080:01C535BB] X-SW-Source: 2005-q1/txt/msg00037.txt.bz2 Here is the GDB backtrace: (gdb) file sid Reading symbols from sid...done. (gdb) set args hello.arm.send (gdb) run Starting program: /tmp/local/bin/sid hello.arm.send Program received signal SIGSEGV, Segmentation fault. 0x402786da in arm7f::arm7f_cpu::arm_pbb_run() (this=0x80eb410) at arm-semsw.cxx:677 677 fragpc = vpc->execute.cgoto.frags; (gdb) bt #0 0x402786da in arm7f::arm7f_cpu::arm_pbb_run() (this=0x80eb410) at arm-semsw.cxx:677 #1 0x401f0675 in arm7f::arm7f_cpu::step_arm_pbb() (this=0x80eb410) at arm7f.cxx:571 #2 0x401ef711 in arm7f::arm7f_cpu::step_insns() (this=0x80eb410) at arm7f.cxx:209 #3 0x401da3a3 in sidutil::basic_cpu::step_pin_handler(unsigned) (this=0x80eb4d0) at sidcpuutil.h:278 #4 0x401de50c in sidutil::callback_pin::driven(unsigned) (this=0x80eb410, v=0) at sidpinutil.h:507 #5 0x406887f5 in scheduler_component::generic_scheduler::advance_any() ( this=0x81074d4) at sidpinutil.h:200 #6 0x40681ae2 in scheduler_component::scheduler_component >::advance(unsigned) (this=0x8107478) at compSched.cxx:773 #7 0x406972e4 in sidutil::callback_pin > >::driven(unsigned) (this=0x80eb410, v=1) at sidpinutil.h:507 #8 0x080a6737 in sidutil::output_pin::list_output::driven(unsigned) (this=0x80c4400, v=1) at stl_iterator.h:593 #9 0x0809a84a in cfgroot_component::run(unsigned) (this=0x80c4318) at sidpinutil.h:200 #10 0x080a9efb in sidutil::callback_pin::driven(unsigned) (this=0x80eb410, v=0) at sidpinutil.h:507 #11 0x08060d91 in main (argc=2, argv=0xbfffed64) at mainDynamic.cxx:937 #12 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 >From: fche@redhat.com (Frank Ch. Eigler) >To: "moris dong" >CC: sid@sources.redhat.com >Subject: Re: SMP board : Bug in SID or configuration file ? >Date: 30 Mar 2005 14:03:56 -0500 > > >"moris dong" writes: > > > I tried to set a simple configuration file for a two-processor SMP > > board (see below). I use two loaders and two gloss (angel) > > instances, one per CPU. > >Good. > > > I use a remapper (MMU?) so the addresses generated by the second > > processor will not conflict with the addresses generated by the > > first [...] > >You can also configure a hw-mapper-basic component to remap addresses >(see the "mapped_base" option). > > > > [...] But, when I enable the two CPUs (connect-pin target-sched > > 0-event -> cpu1 & connect-pin target-sched 1-event -> cpu2) I get a > > segmentation fault. > >That's a bug. SID should not SEGV even on bad configuration. Could >run SID under a debugger and report the backtrace at the point of >crash? > > > 1. What is wrong with my configuration file that is causing this > > core-dump ? [...] > >Just glancing over it, nothing obvious is wrong. > > > 3. [...] > > How can I get two processes to run in a thread-like manner, sharing > > the memory, doing locks etc. What is the programing model (pthreads > > ?), how do I write such a program for SID and how do I start it ? > >Such functionality can only be layered above sid, within the OS you >would run on the simulator. GLOSS is the only piece that emulates >some aspect of the software layer, and extending it to implementing >multithreading system calls would be a big job. > >Think of SID as primarily modelling hardware, its components like the >integrated circuits; its configuration like the pattern of connections >etched into a printed circuit board. > > >- FChE _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/