bugGforth - Bugs: bug #26652, disassembler spits out...

 
 

bug #26652: disassembler spits out "DO" for "2>r"

Submitted by:  Shawn K. Quinn <skquinn>
Submitted on:  Sat 23 May 2009 07:13:47 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Bernd Paysan <paysan>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 19 Dec 2015 10:01:30 PM UTC, comment #6:

Works now with the current snapshot even when both (do) and 2>r are identical.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Mon 03 Sep 2012 01:02:05 AM UTC, comment #5:

Whatever the problem was, my self-compiled gforth (up to date as of Mon Aug 27 13:33:48 2012 +0000, on Fedora 17 x86_64) works fine.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)

Horst H. von Brand <vonbrand>
Mon 25 May 2009 07:52:52 AM UTC, comment #4:

If the code for the primitives is the same, then it does not matter if
they are at different addresses, decompile-prim will only find one of
them (the addresses are different anyway in dynamic code generation).

Maybe you (Bernd) can make the decompiler know about DO in a way
similar to BEGIN.

Anton Ertl <anton>
Project Administrator
Mon 25 May 2009 12:19:03 AM UTC, comment #3:

In order, here are the two tests:

skquinn@afterburner:~$ gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
' (do) @ . 134527311 ok
' 2>r @ . 134531731 ok

skquinn@afterburner:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

Shawn K. Quinn <skquinn>
Sun 24 May 2009 06:43:20 PM UTC, comment #2:

I've checked here with GCC 4.3.2 (x86_64 system), and can't reproduce the problem. What seems to be happening is that GCC combines the two identical operations in the primitive (do) and the primitive 2>r to one code segment, which makes it impossible to distinguish the two primitives for the decompiler - you can verify that this is the case by comparing ' (do) @ and ' 2>r @ (should be identical in your case, isn't identical in my case). What version of GCC are you using (gcc -v)? I suppose it's at least gcc 4.4.x, because 4.3.x has a pessimization bug which prevents GCC from even recognising that 2>r might be equal to (do).

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Sat 23 May 2009 07:16:01 PM UTC, comment #1:

Almost forgot: Debian GNU/Linux lenny (5.0), 32-bit i386 system, compiled from source by hand and installed under my home directory.

Shawn K. Quinn <skquinn>
Sat 23 May 2009 07:13:47 PM UTC, original submission:

I have a word which appears as such in source:

: dwithin ( d1 d2 d3 -- f )
2over d- 2>r d- 2r> du<
;

When disassembling this word with "see" in 0.7.0 I get, instead:

: dwithin
2over d-
DO d- 2r> du< ;

So apparently somehow the disassembler is getting "DO" and "2>r" mixed up.

Shawn K. Quinn <skquinn>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by vonbrand (Posted a comment)
  • -unavailable- added by anton (Posted a comment)
  • -unavailable- added by paysan (Posted a comment)
  • -unavailable- added by skquinn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 19 Dec 2015 10:01:30 PM UTCpaysanStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 25 May 2009 07:52:52 AM UTCantonAssigned toNone=>paysan

    Back to the top


    Powered by Savane 3.1-cleanup1