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-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
