Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Verilator does not pass tests on sparc #288

Closed
veripoolbot opened this issue Sep 28, 2010 · 37 comments
Closed

Verilator does not pass tests on sparc #288

veripoolbot opened this issue Sep 28, 2010 · 37 comments
Assignees
@wsnyder
Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor

Author Name: أحمد المحمودي
Original Redmine Issue: 288 from https://www.veripool.org
Original Date: 2010-09-28
Original Assignee: Wilson Snyder (@wsnyder)

Hello,

This issue was reported on Debian bug tracker [1], 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.

The full build log can be found at:
https://buildd.debian.org/fetch.cgi?pkg=verilator&arch=sparc&ver=3.803-1&stamp=1279241597&file=log&as=raw

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598256
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-09-28T07:54:06Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-09-28T10:37:15Z

That's a syntax error in the run-time tests, so the compile log doesn't help much unfortunately.

To debug it,

cd 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-Kz/verilator-3.803/test_c/../test_v/input.vc top.v --trace --debugi 9

IE add "--debugi 9" to the end of the failing command and post results. It's likely a flex/bison issue.

If there's a system I can log in to test it, I can help.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-03T14:41:09Z

Hello,

I got access to one of Debian's sparc machines, then I added |--debugi 9" to the failing command. Please find the result attached.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-10-03T15:39:08Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-03T16:28:49Z

Attached is the output when I added "--gdbbt --debug" (I did not add --debugi 9"). Please note that after the error, verilator did not return to the shell prompt, so I had to suspend it (CTRL+Z).

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-10-05T02:08:56Z

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,

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-07T16:56:14Z

bison self tests passed successfully.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-07T17:35:22Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-10-11T15:00:55Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-11T19:59:18Z

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)

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-11T20:00:32Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-10-11T20:17:30Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-10-16T14:53:50Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-11-22T07:22:54Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2010-12-17T16:25:08Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-12-17T17:19:48Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-01-22T19:33:05Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-01-23T19:02:39Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-01-23T19:24:48Z

Please note that it still fails on sparc.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-04-27T12:36:04Z

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>]'

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-04-27T12:40:37Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-04-27T13:08:02Z

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)

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-10T03:50:25Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-10T03:51:29Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-05-10T19:21:15Z

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/

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-20T15:58:38Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-05-20T16:40:16Z

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.

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-20T17:21:07Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-05-20T17:49:21Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-20T17:56:08Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-05-20T18:10:42Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-20T19:31:56Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-08-20T08:46:00Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-08-21T15:08:54Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-08-23T01:07:24Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: أحمد المحمودي
Original Date: 2011-08-23T14:35:59Z

Wonderful ! Thanks a lot.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-09-15T01:35:52Z

In 3.821

@veripoolbot veripoolbot added area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wsnyder wsnyder

Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot