Jump to content
rawbits

compiling on linux give unknown symbol for CLEAR_STACK

Recommended Posts

Hi All! You are my last hope here.

 

I try to compile a small test program using the CLEAN_START macro from macro.h (v1.06) but it gives me unresolved symbole for CLEAR_STACK in it. I'm using the latest x86-64 release of DASM 2.20.11 from the WUDSN pack. Which BTW seems to bee the latest stable release. (Yeah I know, but I use Eclipse for everything...except for linux. Linux is always problematic.)

 

If I take out the CLEAN_START macro it's working fine. Directly copy&paste it also not works, took out the '.' so it uses global label and now it complains about CLEAN_START itself.

I'm using these things for about 6 years now on Windows and I'm programming 8-bit assembly since '91 - but I can overlook anything ofcourse. Please help! I feel very lost now. :(

 

Tell me if you need more information.

Share this post


Link to post
Share on other sites

Please post a minimal "non-working" example, so that we can help you out. Pretty difficult to diagnose from the information you have given.

Have you included " processor 6502" at the start?

Have you included an org statement before calling the macro?

Share this post


Link to post
Share on other sites

When doing a reply you'll need to click "More Reply Options" down there in the bottom right to access the file attachment options. Use those options to attach your source code file.

Share this post


Link to post
Share on other sites

Or may you simply misspelled CLEAR_START as CLEAR_STACK like the error says? :ponder:

Share this post


Link to post
Share on other sites
Here is what I get in the console. And I hope I attached the source of a basic kernel with the CLEAN_START marco called. I didn't tried this particular file on Windows but the code worked before.


Compiling for hardware ATARI2600 on 2015.03.11. 19:46: /home/rawbits/BitProcessors/ASM/DASM/bin/dasm.linux-x86-64 /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm -o/home/rawbits/RustyBits/Atari2600/example.bin -f3 -v5 -l/home/rawbits/RustyBits/Atari2600/example.lst
Compiler 'DASM' output:
START OF PASS: 1
----------------------------------------------------------------------
SEGMENT NAME INIT PC INIT RPC FINAL PC FINAL RPC
f000 f000
INITIAL CODE SEGMENT 0000 ???? 0000 ????
----------------------------------------------------------------------
1 references to unknown symbols.
1 events requiring another assembler pass.
- Expression in mnemonic not resolved.
--- Unresolved Symbol List
1.CLEAR_STACK 0000 ???? (R )
--- 1 Unresolved Symbol
Unrecoverable error(s) in pass, aborting assembly!
Running 'Stella': /usr/local/bin/stella /home/rawbits/RustyBits/Atari2600/example.bin
Application returned with exit code 0.

example.asm

Share this post


Link to post
Share on other sites

Weird.

 

.CLEAR_STACK (note the dot before) is a local label inside the CLEAN_START macro. Have you checked the macro and made sure that CLEAR_STACK is written with a dot in both cases?

Share this post


Link to post
Share on other sites

I suggest you turn on listing output, then let us see what's actually happening.

I wonder if it might be a CR/LF issue....? Something strange is happening inside that macro. Please post the macro.h file, too.

I see you already generate a list file. Post it!!

Thanks

A

Share this post


Link to post
Share on other sites

I wonder if it might be a CR/LF issue....?

Good catch! Assembling files on a Windows OS without CR/LF makes DASM freak out pretty unpredictable.

Share this post


Link to post
Share on other sites

Good catch! Assembling files on a Windows OS without CR/LF makes DASM freak out pretty unpredictable.

 

It works fine on Windows as everything always. Linux is the one having the problematic cases and struggle like this time.

 

It seems, it is finding some strange bytes in that macro though. (had to rename 'cause site didn't let me upload)

example.lst

macro_h.txt

Share this post


Link to post
Share on other sites

CLEAN_START macro looks fine to me.

 

Have you tried any of the other macros from macro.h? Do they show the same problem? If yes, maybe you have to replace the two byte Windows CR/LF (0x0d/0x0a) with the single byte Linux LF (0x0a).

Share this post


Link to post
Share on other sites
      5  0000 ????
      6  0000 ????				      SEG
      7  f000					      ORG	$F000
      8  f000
      9  f000				   Reset
     10  f000
      0  f000					      CLEAN_START
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\[email protected]'.
      1  f000					      \[email protected]
      2  f000
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '[email protected]'.
      3  f000					      [email protected]
      4  f000		       a2 00		      ldx	#0
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '[email protected]'.
      5  f000					      [email protected]
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '[email protected]'.
      6  f000					      [email protected]
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic ' [email protected]'.
      7  f000				   .CLEAR_STACK  [email protected]
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\[email protected]'.
      8  f000					      \[email protected]
/home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\[email protected]'.
      9  f000					      \[email protected]
     10  f002		       d0 00		      bne	.CLEAR_STACK
     11  f004

Given the above errors in the listing file, it looks pretty certain to me that there are encoding problems in the macro.h file.

I would grab a clean one from somewhere else and try that.

Cheers

A

Share this post


Link to post
Share on other sites

I would grab a clean one from somewhere else and try that.

 

But from where? Also it's working on Windows. And why the vcs.h works? They are from the same place btw and I use them some years now.

 

CLEAN_START macro looks fine to me.

 

Have you tried any of the other macros from macro.h? Do they show the same problem? If yes, maybe you have to replace the two byte Windows CR/LF (0x0d/0x0a) with the single byte Linux LF (0x0a).

 

I didn't tried others. Will try them soon. Yes, I have tried to save them with only LF line ending and also with different encodings.

Share this post


Link to post
Share on other sites

I think possibly its your "different encodings". I've been using the DASM under Linux for years, and don't have a problem with my macro.h, which I just confirmed has DOS style newlines. The macro file should be encoded as US-ASCII, but unless something weird happened, it should have been so in the first place.

 

If all else fails, download the latest bB and extract the macro.h from there, as-is. That's the one I've been using. If the problem persists, use the dasm from there too, though it's identical to the latest SourceForge binary package.

Share this post


Link to post
Share on other sites

A look at the binary version of the macro.h file you posted, particularly around the macro, doesn't show any problems. It has 0D/0A pairs as expected.

So, I now think you have a dud assembler. It looks like you're running a 64 bit linux version. I recall 64 bit code being dodgy due to the really really dodgy C in DASM.

Switch to the 32 bit version and I bet all your problems disappear.

Cheers

A

Share this post


Link to post
Share on other sites

I just confirmed that the version of DASM in the WUDSN compilers package is the older 2.20.11, before we added various fixes, including 64-bit fixes. If I use the 64-bit WUDSN one to assemble with CLEAN_START (or anything for that matter) I get a segfault partway through. If I use the post-fixed 64-bit dasm, it works fine for me.

 

I've sent JAC! a PM with the info so he can update the WUDSN compiler package.

Share this post


Link to post
Share on other sites

I just confirmed that the version of DASM in the WUDSN compilers package is the older 2.20.11, before we added various fixes, including 64-bit fixes. If I use the 64-bit WUDSN one to assemble with CLEAN_START (or anything for that matter) I get a segfault partway through. If I use the post-fixed 64-bit dasm, it works fine for me.

 

I've sent JAC! a PM with the info so he can update the WUDSN compiler package.

You are a real hero! :) Thanks! Just compiled the 2014.03.04 source and it works perfectly. BTW versioning is gay or what?

 

Thank you all for the answers! You are an awesome community to help me this quick.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...