search

bebbo / binutils-gdb

Unofficial mirror of sourceware binutils-gdb repository. Updated daily.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
GNU General Public License v2.0
3 stars 3 forks source link

GNU as fails to compile .s file generated by Free Pascal #5

Closed chainq closed 5 years ago

chainq commented 5 years ago

Free Pascal normally uses vlink/vasm on Amiga as backend, but I now wanted to give a try to your updated GNU binutils, especially because I hope it might allow using stabs debug info, which is not really supported by vlink for Amiga HUNK outputs.

Sadly, GNU as fails with an error message, while trying to compile this .s file with the following error messages:

athreads.s: Assembler messages:
athreads.s:5646: Error: alignment padding (1 byte) not a multiple of 2
athreads.s:5646: Error: alignment padding (1 byte) not a multiple of 2

I cannot really see anything wrong with the code in that line, and we have a similar construct in many other assembler files which compile just fine. It's possible that FPC does something wrong, but we use the same assembler output for vasm (which has a GNU compatibility mode) and also we support several other m68k targets too (Linux, NetBSD), and they all work.

My host platform is macOS.

Note: Free Pascal is otherwise self-hosted, we just use binutils or any other linker/assembler as backend on platforms which our internal linker and assembler doesn't support yet.

chainq commented 5 years ago

Ugh, sorry, I realized I should probably have opened this ticket against the bebbo/binutils-gdb repository...

bebbo commented 5 years ago

I converted the errors into warnings. please test.

chainq commented 5 years ago

Sorry for the lack of response, I actually neglected this a bit, because to be honest, changing the error to a warning felt like a beauty patch on this issue, not a fix... I kept thinking about it, though.

I read somewhere in one of the forums, that you merge .rodata sections with .text sections to ease access to shorten access to tables in the code, which is good and understandable, but actually, it might cause this issue. We do try to align our .text sections with .balignw 4,0x4e71, where 0x4e71 is just the NOP instruction of course.

Now. If the size of the previous .rodata section is odd, this might cause an issue, because the assembler won't be able to align it to an even number, using the NOP bitpattern (which is two bytes long). Therefore, I THINK the assembler should take care of aligning the size of a .rodata sections if it decides to merge them with a .text section. Any insight on this?

BTW, in my sample .s file I added an extra character to the previous .rodata section before the error occurs (in a .text section), and then the issue indeed disappeared.

In either case, I really think changing this to a warning is a wrong fix. Thank you.

bebbo commented 5 years ago

Sorry for the lack of response, I actually neglected this a bit, because to be honest, changing the error to a warning felt like a beauty patch on this issue, not a fix... I kept thinking about it, though.

changing this to a warning also means that the padding is applied - somehow - since a word does not fit into a byte, the generared binary should work.

chainq commented 5 years ago

I see. Thanks for the clarification.