What could be wrong in this?

[OSMAN]

Hi,

This is disgusting to happen when updating my Linux system. I was developing an OS on an (older 32bit) Debian, and the OS compiled fine, but now I have installed brand new Kubuntu (gcc4 etc... 64bit) and the following tells why it will not compile anymore:

Code: Select all

 Error: suffix or operands invalid for `mov' 

The temporary file where this is, is deleted and always named differently by the compiler, so I can't catch it.

Could you know about the compilers where the difference was, since my source code is exactly the same (and the tools?!) that worked in Debian?

[Solar]

Insufficient data. Do you use NASM or GAS for your assembler parts? Does the error occur for assembler or for C source (or whatever language you use)?

Are you using the system toolchain, i.e. the already-installed compilers? What is the target of those tools?

If you now use a 64bit-targeted toolchain on 32bit-targeted assembler, that would be the point where I'd be looking for changes in assembler syntax between 32bit and 64bit targets.

[OSMAN]

I'm using NASM, and I'm not sure about the toolchains, for there was not a single preinstalled development tool on Kubuntu for some reason. The programs are 64bit on 64bit Kubuntu, but why would they be outputting 64bit binary as defaulf now. Hey, do I have to specify BITS 32 in assembly code in case that's not defaulted? (And I think it was the assembly part, since I don't have much inline assembly in C.)

[OSMAN]

Didn't work, BITS 32. ???

[bluecode]

but why would they be outputting 64bit binary as defaulf now

Because your running a 64bit system? Is there any reason why they should not be outputting 64bit binaries? Nonetheless you have to tell gcc/g++ for which architecture you want to compile. Just read the manpage.

quoting from the manpage:

Hardware Models and Configurations

Earlier we discussed the standard option -b which chooses among different installed compilers for completely different target machines, such as VAX vs. 68000 vs. 80386.
In addition, each of these target machine types can have its own special options, starting with -m, to choose among various hard- ware models or configurations---for example, 68010 vs 68020, floating coprocessor or none. A single installed version of the compiler can compile for any model or configuration, according to the options specified.

Hey, do I have to specify BITS 32 in assembly code in case that's not defaulted?

Yes, you should do this, but that should be no problem at all, because nasm does not support 64bit (for that you might want to use yasm).

And I think it was the assembly part, since I don't have much inline assembly in C.

I wouldn't bet on that. You should try to find out where that error occurs.

[OSMAN]

Thank you for enlightening me. I added a gcc option -m32 and to ld "OUTPUT_ARCH("i386")". Now the problem is gone, but there's another one arisen.
This:

Code: Select all

BFD: Dwarf Error: DW_FORM_strp offset (1730) greater than or equal to .debug_str size (1569).
BFD: Dwarf Error: DW_FORM_strp offset (1660) greater than or equal to .debug_str size (1569).
BFD: Dwarf Error: DW_FORM_strp offset (1602) greater than or equal to .debug_str size (1569).
BFD: Dwarf Error: DW_FORM_strp offset (1660) greater than or ... 
and this for 27 lines.

I don't have a clue where could the problem lay now.

[bluecode]

Dwarf is a debug fileformat, you should perhaps use OUTPUT_FORMAT(elf32-i386) in your linker script.

[OSMAN]

Hey, I got it compiling again! Thank you very much!