[Bug gas/18198] New: On ARM, instruction and data endianness cannot differ
https://sourceware.org/bugzilla/show_bug.cgi?id=18198 Bug ID: 18198 Summary: On ARM, instruction and data endianness cannot differ Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: solrabizna at gmail dot com Flags: security- I'm working on a project targeting ARMv7-A processors with the E bit set. This execution environment has big-endian data and little-endian instructions. The ARM Architecture Reference Manual is very clear on the topic; ARMv7-A instructions can *never* be big-endian. (Some other ARM variants allow big-endian instructions via the B bit, which is separate from the E bit and cannot normally be altered after power-on.) I am aware of -EB/-EL arguments to the assembler; they specify both data and instruction endianness. I've Googled and asked colleagues and pored over the info pages, and I have not found any combination of command-line arguments or assembler directives that allows big-endian data with little-endian instructions. It would be possible for me to eliminate the use of the E bit throughout this particular project. This means that, at least for me, a resolution of "too difficult to support" would be survivable. The underlying problem, however, is that GNU toolchains apparently cannot be used to produce code that operates with the E bit set. This would bother me on principle if nothing else. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18198] On ARM, instruction and data endianness cannot differ
https://sourceware.org/bugzilla/show_bug.cgi?id=18198 --- Comment #2 from Solra Bizna --- I can confirm that this works. (Yay!) Compiling with -EB and passing --be8 to ld results in little-endian instructions and big-endian data. I specifically tested that it correctly handles literal pools, and unadorned .word directives (correctly) come out little-endian in .text sections and big-endian in .data sections. The only remaining bug IMO is in the documentation for the -EB option. It ought to mention --be8, perhaps something like: "In order to run on recent ARM processors, code assembled with -EB generally needs to be linked specially. With the GNU linker, this entails passing --be8 to ld." Do I close this bug and file a new one? Are documentation bugs a thing in this ecosystem? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18256] New: Internal error while assembling for ARM; assertion failure in encode_arm_cp_address
https://sourceware.org/bugzilla/show_bug.cgi?id=18256 Bug ID: 18256 Summary: Internal error while assembling for ARM; assertion failure in encode_arm_cp_address Product: binutils Version: 2.25 Status: NEW Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: solrabizna at gmail dot com I was attempting to assemble a PC-relative coprocessor load. While flailing around to find the right syntax, I happened on an assertion failure. The simplest source file that triggers the assertion failure is one containing a single line: "LDC p0, c0, =." The exact output: : Assembler messages: :1: Internal error! Assertion failure in encode_arm_cp_address at ../../binutils-2.25/gas/config/tc-arm.c line 7873. Please report this bug. The message said I should report it so I'm reporting it. (I know it's the wrong syntax for what I want.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18314] New: On ARM, data gets confused for instructions after ".align" directive
https://sourceware.org/bugzilla/show_bug.cgi?id=18314 Bug ID: 18314 Summary: On ARM, data gets confused for instructions after ".align" directive Product: binutils Version: 2.25 Status: NEW Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: solrabizna at gmail dot com Created attachment 8265 --> https://sourceware.org/bugzilla/attachment.cgi?id=8265&action=edit A simple test file, demonstrating some of the behavior detailed in the report. Compile with "as -EB" and disassemble to see the confusion at work. In my previous bug report, I noted that compiling with -EB and linking with --be8 lead to ".word" directives sometimes being swapped. I also asserted that this was correct behavior. I was wrong, on both counts. I'm now reasonably sure that ".word" directives are not supposed to be swapped. Not being swapped, in fact, is far more useful than the alternative. However, as already witnessed by my previous test, this behavior is not consistent. It turns out that something can get confused when ".align" directives are involved. I noticed that in situations where "ld --be8" (incorrectly) byte swaps data as if it were instructions, "objdump" (incorrectly) disassembles it as instructions. So subsequent testing involved only "as -EB" and "objdump -d". According to my tests, confusion ensues after a ".align" directive is encountered, but only if the location counter is not already aligned, and only if there has been at least one explicit instruction. When confusion occurs, it continues until the next explicit instruction. Labels, ".func" directives, and the character of the explicit instructions do not matter. I found that ".align", ".p2align", and ".balign" are interchangeable for purposes of this bug. I also found that confusion (seemingly) never occurs before the first explicit instruction is emitted, no matter how ".align" directives are used. I also found that confusion only results when the ".align" directive is not given a fill value (and therefore uses NOPs). I set the severity to "minor" because a trivial workaround exists: providing a fill value for every ".align" directive avoids all confusion. P.S. I must confess that I still do not fully understand the things that happen between my source code and the final linked executable that lead to everything being in the right byte order (most of the time). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18347] New: On ARM, "LDR =something" with missing destination register is silently ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=18347 Bug ID: 18347 Summary: On ARM, "LDR =something" with missing destination register is silently ignored Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: solrabizna at gmail dot com Target Milestone: --- A simple test program that demonstrates this problem: MOV r1, r0 LDR =garbage // no destination register MOV r2, r3 Assembles without any error or warning, and disassembles as: <.text>: 0: e1a01000mov r1, r0 4: e1a02003mov r2, r3 The effect is the same if the "garbage" symbol is actually defined. I made this mistake while writing an IO routine, and had to look through the disassembly to figure out why the register had the wrong value. GAS should throw an error when it encounters such an instruction, since there is no sensible way to interpret it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18347] On ARM, "LDR =something" with missing destination register is silently ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=18347 --- Comment #3 from Solra Bizna --- Ah! That explains what's happening. Just tried the patch. It works great. As far as adding some way to suppress the warning... Instruction set extensions mean that an acceptable symbol one day will cause a warning tomorrow. Having some way to suppress the warning would be good. If it's possible, I'd suggest keeping the warning on definitions of the form "X=Y", and having no warning on the rather more explicit (but equivalent, right?) ".set X, Y". If the user really wants a symbol with that kind of name, they oughtn't mind being explicit about it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18314] On ARM, data gets confused for instructions after ".align" directive
https://sourceware.org/bugzilla/show_bug.cgi?id=18314 Solra Bizna changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Solra Bizna --- Binutils from git correctly handles all of my test cases. I believe this is now fixed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
