[BareBones Tutorial] Unrecognized Chars in provided code

[jort13]

Hello guys,

I realize I'm a newbie around here (in fact, I made this account to post this. Have been lurking for a couple of weeks. I'm a Software Engineer mainly dealing in C# and Dynamic C every day, so this is a change of pace for me), and hopefully this is not too obvious of a question, but when I try to compile boot.s as in the BareBones tutorial, I get the following errors:

https://ibb.co/cPcAV6

boot.s: Assembler messages:
boot.s: Warning: end of file not at end of a line; newline inserted
boot.s:46: Warning: .type pseudo-op used outside of .def/.endef: ignored.
boot.s:46: Error: junk at end of line, first unrecognized character is `_'
boot.s:109: Warning: .size pseudo-op used outside of .def/.endef: ignored.
boot.s:109: Error: junk at end of line, first unrecognized character is `_'

The code is directly pasted (I wanted to be sure it was not a typo on my end) into Visual Studio Code and compiled through Cygwin's Terminal (I'm running W10) / gcc.

The lines referenced in the error can be seen here:
https://ibb.co/cywUq6
https://ibb.co/fJFTiR

Code: Select all

46:    .type _start, @function
109:   .size _start, . - _start

I have read through the BareBones tutorial three times, searched the wiki and forum, as well as stack overflow and general googling. Of course, normally, an error like this is a typo. But removing the _ characters does not fix the problem. I tried removing the _ characters on the start function and its calls, but to no avail.

Thank you!

[MichaelPetch]

Your problem is related to using Visual Studio editor which by default saves text files with Windows End of Line characters. That is a Carriage Return followed by a line feed. Unfortunately your GCC in Cygwin expects files to have Unix end of line characters which is just a single Line Feed. GCC is getting confused with the Windows End of Line characters. What you can do is change the default EOL in Visual Studio by use the "file" menu, "Advanced Save Options...", select "Line Endings" and change to "Unix (LF)". Then you'll have to reload your .s file and save it again.

Alternatively you can load your .s file in Visual Studio, then do "File" menu "Save <file> As..." then in the popup box click the down arrow to the right of the "save" button select "Save with encoding" and then "line endings" and change to "Unix (LF)". This process will change it for that file only.

Cygwin may also me able to convert your files with the dos2unix command. specify dos2unix filename.s which should change the end of line characters to be Unix LF.

[zaval]

the problem more probably is not in EOL characters used, gcc builds for Windows understand both EOL and even directory separator specific for it.
First, the warning "end of file not at end of a line; newline inserted" shows GCC wants an empty line at the end of file, put it there for it.
Second, this seems to be the reason of errors:

For COFF targets, this directive is permitted only within .def/.endef pairs. It is used like this:

It looks like you use COFF as your target output format. Then you should use .def/.endef pairs and put .type there. But I fear you use gcc compiled for Windows targetting for your OS targetting. That hardly would work with gcc...

You need a cross-compiler for that.

[MichaelPetch]

Ah I removed a post I just made and realized that this wouldn't be EOL related and that this is a result of the format being used not supporting certain directive the same way. So yes, a good reason to use an elf cross compiler. So I do agree with your assessment when I looked at the output again

[iansjack]

Just to add further explanation.

After ignoring the .type and .size directives (for reasons explained above) the rest of each line is invalid. Hence the errors "junk at end of line".

[jort13]

Thank you all for the replies. Using Dos2Unix or forcing the correct encoding through either VS Code or VIM didn't do much.
It turned out to be the cross-compiler, indeed. It used the windows one instead of the target one. I rebuilt it and it compiles perfectly fine now (since it uses the correct cross-compiler now)

Thanks!