Verilator

the build on sparc fails at the following:

 | make[2]: Entering directory `/build/buildd-verilator_3.803-1-sparc-KKtZnz/verilator-3.803/test_c'
 | /usr/bin/perl /build/buildd-verilator_3.803-1-sparc-KKtZnz/verilator-3.803/test_c/../bin/verilator        --cc -f /build/buildd-verilator_3.803-1-sparc-K
z/verilator-3.803/test_c/../test_v/input.vc top.v --trace
 | %Error: ../test_v/top.v:8: syntax error, unexpected $undefined
 | make[1]: *** wait: No child processes.  Stop.

It does seem to be dieing when parsing the first module, but doesn't tell me much else

Please try --gdbbt --debug that should make a backtrace.

It looks like bison is confused and never takes the first token. The next debug output should have been:

--accepting rule at line 247("module")
   lexToBison  TOKEN=344 "endprogram" 
Next token is token "module" ()
Shifting token "module" ()
Entering state 10

It might be worth running the bison kit's self tests, maybe it's just misinstalled.

Beyond that to debug further it'll be a matter of editing the bison output to add print statements, or stepping in gdb to find where it diverges from the other OSes.

Sorry no simple fix,

bison self tests passed successfully.

Please explain what you meant by "editing the bison output to add print statements ...". In other words, what is the other step to debug this problem

I think the best thing to do is have a window on x86 linux and another on sparc, and run verilator (the line above) with --debug

At the top this will print the raw command being executed; what I have below is probably close enough to work. Now add a breakpoint where it first passes a token to bison and step or trace as needed until you see a difference. For example:

cd test_regress
gdb ../verilator_bin_dbg
dir ../src
dir ../src/obj_dbg
break V3ParseImp::bisonParse
run --debug -cc -f ../test_v/input.vc top.v --trace
c  # or s

Ok, here's what I have got

sparc
=====
Breakpoint 1, V3ParseImp::bisonParse (this=0x431d88) at verilog.y:3038
3038    verilog.y: No such file or directory.
        in verilog.y
(gdb) s
V3ParseImp::parsep () at ../V3ParseImp.h:265
265         static V3ParseImp* parsep() { return s_parsep; }
(gdb) s
V3ParseImp::debugBison () at ../V3ParseImp.h:236
236             if (VL_UNLIKELY(level < 0)) level = v3Global.opt.debugSrcLevel("bison");
(gdb) s
237             return level;
(gdb) s
238         }
(gdb) s
V3ParseImp::bisonParse (this=0x431d88) at verilog.y:3039
3039    verilog.y: No such file or directory.
        in verilog.y
(gdb) s
yyparse () at V3ParseBison_pretmp.c:6224
6224    V3ParseBison_pretmp.c: No such file or directory.
        in V3ParseBison_pretmp.c
(gdb) s
yyparse () at V3ParseBison_pretmp.c:6225
6225    in V3ParseBison_pretmp.c
(gdb) 

i386
====Breakpoint 1, V3ParseImp::bisonParse (this=0x834e098) at verilog.y:3038
3038    verilog.y: No such file or directory.
        in verilog.y
(gdb) s
V3ParseImp::parsep () at ../V3ParseImp.h:265
265         static V3ParseImp* parsep() { return s_parsep; }
(gdb) s
V3ParseImp::debugBison () at ../V3ParseImp.h:236
236             if (VL_UNLIKELY(level < 0)) level = v3Global.opt.debugSrcLevel("bison");
(gdb) s
237             return level;
(gdb) s
238         }
(gdb) s
V3ParseImp::bisonParse (this=0x834e098) at verilog.y:3039
3039    verilog.y: No such file or directory.
        in verilog.y
(gdb) s
yyparse () at V3ParseBison_pretmp.c:6187
6187    V3ParseBison_pretmp.c: No such file or directory.       <====== didn't get there on sparc !
        in V3ParseBison_pretmp.c
(gdb)
6224    in V3ParseBison_pretmp.c
(gdb)
6225    in V3ParseBison_pretmp.c
(gdb)

Please note that sparc did not go to line 6187 of V3ParseBison_pretmp.c

Unfortunately the line numbers may not line up because of the different bison versions, which is related to the problem. So you can't know easily what it didn't do.

In theory :) you can copy V3ParseBison.c from the x86 to the sparc version, "make" and see if it still shows the problem, or vice-versa. Then at least the line numbers will line up. It's worth a try but might not even compile.

I think what may help is if you get the source code to print out as it goes, it may make it more obvious when the paths diverge by looking at the code difference rather than line numbers; I think the "dir ../src" and "dir ../src/obj_dbg" should give GDB the right information (edited earlier reply to show this).

The key is to keep "c" continuing until there's the syntax error.

Hello,

1. Both sparc & i386 chroots had the same bison version
2. I checked the diff between the resulting V3ParseBison.c file on both sparc & i386, and they were exactly the same.
3. The dir command did not show the lines in V3ParseBison_pretmp.c, actually I cannot find that file in the source directory after build.

From aelmahmoudy:

I just tried to build old versions of verilator on sparc, and I found that 3.720 was the last version that passed the tests on sparc. So it must be some change from 3.720 to 3.800 that caused the problem.

Hello,

Another bug ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607033 ) was filed on Debian, which I think might help debugging this issue. When building verilator 3.805 on hppa arch, the following error message appeared:

make[2]: Entering directory `/build/buildd-verilator_3.805-1-hppa-HEPYtD/verilator-3.805/test_c'
/usr/bin/perl /build/buildd-verilator_3.805-1-hppa-HEPYtD/verilator-3.805/test_c/../bin/verilator        --cc -f /build/buildd-verilator_3.805-1-hppa-HEPYtD/verilator-3.805/test_c/../test_v/input.vc top.v --trace
%Error: Internal Error: ../V3Ast.cpp:491: Node has no back, already unlinked?
%Error: Internal Error: See the manual and http://www.veripool.org/verilator for more assistance.
%Error: Command Failed /build/buildd-verilator_3.805-1-hppa-HEPYtD/verilator-3.805/test_c/../verilator_bin --cc -f /build/buildd-verilator_3.805-1-hppa-HEPYtD/verilator-3.805/test_c/../test_v/input.vc top.v --trace
make[2]: *** [prep] Error 9

Can you login there? That's a library routine error, so it's all about who's calling it.

cd test_c
../bin/verilator  --debug --gdbbt --cc -f ../test_v/input.vc top.v --trace

Hello,

Unfortunately, I still didn't get access on an hppa machine (I requested it at the same day I received the hppa build error). Anyways, verilator 3.810 did pass on hppa. I hope this gives you a clue.

Glad it passes, but I don't see an obvious reason why it was broken before. I'll leave this issue open for a little while if something else turns up.

Please note that it still fails on sparc.

Now verilator 3.812 has the same failure on powerpc architecture, did you change anything from 3.811 to 3.812 that might cause this failure ?

The build log can be found on: https://buildd.debian.org/status/fetch.php?pkg=verilator&arch=powerpc&ver=3.812-1&stamp=1302429189

The build log for 3.811 (which was the last successful build for powerpc arch) can be found on: https://buildd.debian.org/status/fetch.php?pkg=verilator&arch=powerpc&ver=3.811-1&stamp=1297876086

By quickly checking both build logs I noticed the following:

• In the 3.811 build, gcc 4.4 was used, while in the 3.812 build, gcc 4.5 is used.
• There are those warning while building 3.812:

 ../V3AstNodes.h: In member function 'virtual std::string AstBufIf1::emitC()':
 ../V3AstNodes.h:3184:49: warning: converting 'false' to pointer type for argument 1 of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
 ../V3AstNodes.h: In member function 'virtual std::string AstBufIf1::emitSimpleOperator()':
 ../V3AstNodes.h:3185:62: warning: converting 'false' to pointer type for argument 1 of 'std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'

I suspect that the cause of the failure is probably the toolchain changes, rather than the changes introduced in 3.812

Toolchain differences:

                    3.811          3.812
                    =====          =====
  linux-libc-dev    2.6.32      |  2.6.38
  gcc/g++           4.4.5       |  4.5.2
  binutils          2.20.1      |  2.21.0.20110327
  libstdc++6        4.4.5       |  4.6.0 (or 4.5.2)

I fixed the compile warnings. If you can figure out how to get me a shell on a system that shows this I'll debug it, otherwise I think we're stuck.

BTW a VNC session or equivelent would be fine too, I don't mind if you need to look over my shoulder for security reasons.

Hello,

I was talking to a Debian Developer today, and he suggested using Qemu, it can emulate a MIPS machine on a x86 machine for example. You can get the Debian images from: http://people.debian.org/~aurel32/qemu/

For powerpc, I would suggest using debian_squeeze_powerpc_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/powerpc/

I built verilator under the qemu image suggested and it works fine. If you could point to a qemu image that fails, I'll debug it.

Oh yes, the build fails for the wheezy/sid release. You can upgrade the image you've got as follows:

1) Edit /etc/apt/sources.list, you should fine a line(s) like this:

deb http://ftp.debian.org/debian squeeze main contrib non-free

You might find 'stable' instead of 'squeeze', just replace 'squeeze' (or stable) with 'unstable', and save the file.

2) Run: apt-get update && apt-get dist-upgrade Please note that might be quite a download !

With /etc/apt/sources.list

deb http://ftp.debian.org/debian unstable main
deb-src http://ftp.debian.org/debian unstable main
deb http://security.debian.org/ unstable/updates main
deb-src http://security.debian.org/ unstable/updates main
deb http://ftp.debian.org/debian unstable-updates main
deb-src http://ftp.debian.org/debian unstable-updates main

Updating doesn't seem to do anything

Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Wierd, are you sure that you first ran: apt-get update

Er, now I'm getting the below. Maybe there's some network oddity? A "wget http://ftp.debian.org" seems to work.

apt-get update
Ign http://security.debian.org unstable/updates Release.gpg
Ign http://security.debian.org/ unstable/updates/main Translation-en
Ign http://security.debian.org/ unstable/updates/main Translation-en_US
Ign http://security.debian.org unstable/updates Release
Hit http://ftp.debian.org unstable Release.gpg
Ign http://ftp.debian.org/debian/ unstable/main Translation-en
Ign http://security.debian.org unstable/updates/main Sources
Ign http://ftp.debian.org/debian/ unstable/main Translation-en_US
Ign http://security.debian.org unstable/updates/main powerpc Packages
Err http://security.debian.org unstable/updates/main Sources
  404  Not Found [IP: 128.31.0.36 80]
Err http://security.debian.org unstable/updates/main powerpc Packages
  404  Not Found [IP: 128.31.0.36 80]
Ign http://ftp.debian.org unstable-updates Release.gpg
Ign http://ftp.debian.org/debian/ unstable-updates/main Translation-en
Ign http://ftp.debian.org/debian/ unstable-updates/main Translation-en_US
Hit http://ftp.debian.org unstable Release
Ign http://ftp.debian.org unstable-updates Release
Ign http://ftp.debian.org unstable-updates/main Sources
Ign http://ftp.debian.org unstable-updates/main powerpc Packages
Hit http://ftp.debian.org unstable/main Sources/DiffIndex
Hit http://ftp.debian.org unstable/main powerpc Packages/DiffIndex
Err http://ftp.debian.org unstable-updates/main Sources
  404  Not Found [IP: 130.89.149.226 80]
Err http://ftp.debian.org unstable-updates/main powerpc Packages
  404  Not Found [IP: 130.89.149.226 80]
W: Failed to fetch http://security.debian.org/dists/unstable/updates/main/source/Sources.gz  404  Not Found [IP: 128.31.0.36 80]

W: Failed to fetch http://security.debian.org/dists/unstable/updates/main/binary-powerpc/Packages.gz  404  Not Found [IP: 128.31.0.36 80]

W: Failed to fetch http://ftp.debian.org/debian/dists/unstable-updates/main/source/Sources.gz  404  Not Found [IP: 130.89.149.226 80]

W: Failed to fetch http://ftp.debian.org/debian/dists/unstable-updates/main/binary-powerpc/Packages.gz  404  Not Found [IP: 130.89.149.226 80]

E: Some index files failed to download, they have been ignored, or old ones used instead.

That's normal, because there aren't any security/updates/backports for the unstable release.

Anyways, I beleive that now running: apt-get dist-upgrade Should be fetching quite a bit of a download.

I got it to start updating (it's not unstable-updates but still squeeze-updates) but it runs out of disk space.

Sorry; if you can point me to a qcow image that fails I'll look at it, but don't have more time now to play with this.

I've prepared a Qemu powerpc image (size is 1GB !), I intend upload it during this week and put the link when the upload is done.

Here's the link to the PowerPC image: http://people.ubuntu.com/~aelmahmoudy/ppc.img

Great work making the image. I was able to reproduce it and tracked it down to (paraphrasing)

int V3Parse::x() { y(); }

where I was missing a return - which seems to work ok on most architectures! Unfortunately lint was turned off on that file to get around flex warnings and I never noticed.

Fixed in git towards 3.821.

Wonderful ! Thanks a lot.