unaligned opcodes detected in executable segment

Post by **KanedaFr** » Tue Mar 11, 2014 1:37 pm

Hi,

Since I'm now using the -g arg, this error jumped on the assembly step.
If I use this

      ; .align 1
     ; .align 2
       .even
tiles:
	dc.b	0xf0
	dc.b	0xf0
	dc.b	0xf0
	dc.b	0xf0

assembly fails with an "unaligned opcodes detected in executable segment" error

If I use

Code: Select all

      ; .align 1
     ; .align 2
       .even
tiles:
	dc.w	0xf0f0
	dc.w	0xf0f0

it works/assembles.

If I don't use the "-g" arg, it works/assembles (but not aligned?)

It seems pretty much the same issue that in this link

Could someone already get this? confirm it ? fix it ? tell me how to handle it ?

Graz · Post by **Graz** » Wed Mar 12, 2014 5:03 pm

Don't put data in the .text segment. Put this in .rodata.

Post by **KanedaFr** » Wed Mar 12, 2014 5:33 pm

err....
and how to do that ?

Graz · Post by **Graz** » Wed Mar 12, 2014 6:36 pm

Code: Select all

.rodata
       .even
tiles:
   dc.b   0xf0
   dc.b   0xf0
   dc.b   0xf0
   dc.b   0xf0

Don't forget .text before any actual code.

Chilly Willy · Post by **Chilly Willy** » Thu Mar 13, 2014 12:47 am

The other "solution" is ALWAYS align the pc before code that follows data, even if the data seems like it should be aligned.

Code: Select all

   .even
tiles:
   dc.b   0xf0
   dc.b   0xf0
   dc.b   0xf0
   dc.b   0xf0 

   .even

I'd also take a close look at the .even directive to make sure there's not something funny going on... I prefer to use .align instead.

Post by **KanedaFr** » Thu Mar 13, 2014 1:12 am

I think I already tried that

Code: Select all

  .align 2
tiles: 
   dc.b   0xf0 
   dc.b   0xf0 
   dc.b   0xf0 
 .align 2

and it produced the same error

Again, it only occurs while using the debug command (-g)
Tried removing -O1 with same result...

Post by **KanedaFr** » Fri Mar 14, 2014 11:45 am

so

Code: Select all

unknown pseudo-op: `.rodata'

and I confirm

Code: Select all

   .align 2
xxxx
   .align 2

produces the same error

Until someone got the answer, I'll need to update genres to export compressed data with dc.w and not dc.b

Chilly Willy · Post by **Chilly Willy** » Fri Mar 14, 2014 5:43 pm

That's a weird compiler bug.

I imagine it's just on the old gcc you use with the toolkit. I don't think I've ever seen that on newer versions.

Oh, the way to put the data in .rodata is like this

Code: Select all

   .section .rodata

You can find the directives and everything else for gas here:
https://sourceware.org/binutils/docs-2.22/as/index.html

Post by **KanedaFr** » Fri Mar 14, 2014 11:23 pm

I updated genRes to export dc.w not dc.b : no more problem
it's more a trick than a fix , perhaps Stef will find some time to test / fix it

Stef · Post by **Stef** » Sat Mar 15, 2014 10:49 am

Definitely weird bug, i never experienced it because i don't use debug option for compilation but so i guess i will meet it to it i enable them. What specific option make the compiler to fail ? -g ?

Post by **KanedaFr** » Sat Mar 15, 2014 3:10 pm

yes, it's the -g option
if you use dc.b and -g, it will produce an error
look at the link on first post, perhaps it's the fix
...

Stef · Post by **Stef** » Sat Mar 15, 2014 6:30 pm

Tried to compile with -g option and indeed:

res/image_res.s:7603: Error: unaligned opcodes detected in executable segment

Weird... all my data are aligned to word and declared in .text or .rodata section. I'm afraid that is a stupid GCC bug and it is a pain in the ass for my rescomp tool :-/