Doh! I realize I forgot to attach the project.
On Fri, Oct 23, 2009 at 4:18 PM, Peter LaDow <[email protected]> wrote: > On Tue, Oct 20, 2009 at 10:04 PM, Tristan Gingold <[email protected]> wrote: >> I can't reproduce the crash: >> >> $ ../fpga_stamp_t0 >> ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:216:5:@3400ns:(assertion failure): >> Halt requested. >> ../fpga_stamp_t0:error: assertion failed >> ../fpga_stamp_t0:error: simulation failed > > Yep! That's what I expected... > >> What is your output ? >> (I don't really use the same environment that yours - that may explain >> things) > > Hmm.... Here's what I get when I run it in gdb. > > (gdb) r --trace-processes > Starting program: > /home/pete/ghdl-pladow/fpga_stamp/fpga_stamp_m0/test/fpga_stamp_t0 > --trace-processes > [Thread debugging using libthread_db enabled] > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).tcon_con [0932A328] > [New Thread 0xf7c6c0 (LWP 16476)] > [New Thread 0x5f7db70 (LWP 16479)] > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).gpio_con [0932A328] > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).tcon_con > [0932E9E8] > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).clk_gen(0).clk_con > [0932F970] > Now is 0ms +0 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xf7c6c0 (LWP 16476)] > 0xec835356 in ?? () > (gdb) bt > #0 0xec835356 in ?? () > #1 0x08094bb0 in grt.signals.compute_resolved_signal (resolv=0x9329910) > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-signals.adb:1796 > #2 0x08096e72 in grt.signals.update_signals () > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-signals.adb:3075 > #3 0x0809c84e in grt.processes.simulation_cycle () > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-processes.adb:692 > #4 0x080a1ad3 in __ghdl_run_through_longjump ( > func=0x809c832 <grt.processes.simulation_cycle>) > at ../../../gcc-4.3.4/gcc/vhdl/grt/config/linux.c:312 > #5 0x0809c266 in grt.processes.simulation () > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-processes.adb:840 > #6 0x080a72b8 in grt.main.run () > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-main.adb:154 > #7 0x080a58e4 in ghdl_main (argc=2, argv=Cannot access memory at > address 0xe58955c7 > ) > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/ghdl_main.adb:49 > #8 0x080a1ea6 in main (argc=Cannot access memory at address 0xe58955c3 > ) at ../../../gcc-4.3.4/gcc/vhdl/grt/main.adb:24 > (gdb) info threads > 2 Thread 0x5f7db70 (LWP 16479) 0x00d76416 in __kernel_vsyscall () > * 1 Thread 0xf7c6c0 (LWP 16476) 0xec835356 in ?? () > (gdb) thread 2 > [Switching to thread 2 (Thread 0x5f7db70 (LWP 16479))]#0 0x00d76416 > in __kernel_vsyscall () > (gdb) bt > #0 0x00d76416 in __kernel_vsyscall () > #1 0x007e7fa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 > #2 0x0808fb9c in wait_for_function_complete () at src/tcon_thread.c:86 > #3 0x0808f633 in tcon_write (l=0xb7e00468) at src/tcon_t0.c:173 > #4 0x008b6bda in ?? () from /usr/lib/liblua-5.1.so > #5 0x008c1d5a in ?? () from /usr/lib/liblua-5.1.so > #6 0x008b70c0 in ?? () from /usr/lib/liblua-5.1.so > #7 0x008b2061 in ?? () from /usr/lib/liblua-5.1.so > #8 0x008b66e3 in ?? () from /usr/lib/liblua-5.1.so > #9 0x008b6745 in ?? () from /usr/lib/liblua-5.1.so > #10 0x008b1e88 in lua_pcall () from /usr/lib/liblua-5.1.so > #11 0x0808f9e0 in lua_thread_entry (p=0x0) at src/tcon_t0.c:402 > #12 0x007e3935 in start_thread () from /lib/libpthread.so.0 > #13 0x0071894e in clone () from /lib/libc.so.6 > (gdb) > > This one I expect. This is the Lua script running in its own thread > (thread 2). It is waiting on a condition for the VHDL to complete its > side of things. Now, the VHDL sets the condition by calling > exec_tcon() (in tcon_t0.c in tools/tb/tcon_t0/src). But things are > getting messed upon the VHDL side of things, and I'm not sure where. > > So, to try and track things down I sprinkled some printf's and > assert's throughout my code to see where this was happening. I've > narrowed it down to the wait in the tcon_write function in the VHDL. > I've attached another project with the extra debug output. Here's > what I get: > > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).tcon_con [081E7328] > Calling init_tcon <-- This is on the C side, called from the VHDL. > This is where the extra thread is created > Calling tcon_gpio_clrdir with clrdir=7 <-- This is also on the C > side, but called from the Lua thread > Calling exec_tcon with 0 <-- This is on the VHDL side, called from > the tcon process in tcon_t0. The function number corresponds with a > tcon function of 'none' in the VHDL > Returning 9 from exec_tcon <-- This is after the exec_tcon is done, > returning with a new function code. It blocks in exec_tcon() until > the Lua side sets a function code. The 9 indicates a new function, > which is 'gpio_clr_dir' > Calling exec_tcon with 9 <-- After the VHDL is done, it calls > exec_tcon with the function code. The Lua thread is blocked waiting > for the VHDL to finish. This call signals that the VHDL is done. It > then blocks waiting for a new function. > Calling tcon_write with req=0, addr=1, data=2710 <-- On the Lua side > of things again. It sets the function code (along with the data) and > blocks until the VHDL is done. > Returning 2 from exec_tcon <-- Back to the VHDL side. The VHDL > returns 2, which corresponds to a 'write' > ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:180:11:@0ms:(assertion > note): VHDL: Executing tcon_write <-- Now the VHDL assertions > showing the tcon_write is running in the VHDL > ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:144:7:@0ms:(assertion note): > VHDL: Waiting for tcon_ack <-- Here the VHDL is waiting for up to > 1ps for the tcon_ack to get set to '1' (though it occurs in 0 time). > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).gpio_con [081E7328] > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).tcon_con > [081EB9E8] > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).clk_gen(0).clk_con > [081EC970] <-- We see the clocker_t0 processes run, which > corresponds with the write we were doing (trying to write the clock > generation modules). Then it goes kaput after this. > Now is 0ms +0 > ../fpga_stamp_t0:error: invalid memory access (dangling accesses or > stack size too small) > ../fpga_stamp_t0:error: simulation failed > > The fact that is runs fine on your system does seem strange. Now, I > don't know what build you are using. Perhaps you can send me a > compiled version of fpga_stamp_m0 and I can see if that works for me? > If that compiled version works, then it would point to a problem with > my GHDL build. If it poops out on my end, then it would point to > library issues (perhaps buggy pthread or Lua libraries). > > Thanks, > Pete >
ghdl-pladow-debug.tar.bz2
Description: BZip2 compressed data
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
