Why does Ghidra disassembler use x86 data mnemonics on aarch64?

[shamefulCake1]

I have to say that I am not good at either x86, aarch64, Ghidra, or assembly in general, but I am a bit confused by the disassembler output in case of "raw data".

This is my source:

        .text
        .globl _start
        min = 0                          /* starting value for the loop index; **note that this is a symbol (constant)**, not a variable */
        max = 10                         /* loop exits when the index hits this number (loop condition is i<max) */
_start:
        mov     x19, min       /* the value in register 19 = loop index */
loop:

        /* ... body of the loop ... do something useful here ... */
        mov     x0, 1           /* file descriptor: 1 is stdout */
        adr     x1, msg         /* message location (memory address) */
        mov     x2, len         /* message length (bytes) */

        mov     x8, 64          /* write is syscall #64 */
        svc     0               /* invoke syscall */


        /* .. useful things done */
        add     x19, x19, 1     /* increment the loop counter */
        cmp     x19, max        /* see if we've hit the max */
        b.ne    loop            /* if not, then continue the loop */

        mov     x0, 0           /* set exit status to 0 */
        mov     x8, 93          /* exit is syscall #93 */
        svc     0               /* invoke syscall */
        .byte   0xFE

        .data
msg:    .ascii      "Hello, world!\n"
mylabel: len=    . - msg
        .byte   0xFF

I am building it with GNU as and lld from LLVM. (Actually, from Android Ndk)

It is not really important what is inside, but there is a symbol table entry in the resulting ELF, and here is how Ghidra disassembles it:

                      .symtab::00000060 0c 00 00 00 00 00 01 00  Elf64_Sym                            [4]
                                        5c 01 21 00 00 00 00 00 
                                        00 00 00 00 00 00 00 00
                         .symtab::00000060 0c 00 00 00             ddw          Ch                      st_name                   loop
                         .symtab::00000064 00                      db           0h                      st_info
                         .symtab::00000065 00                      db           0h                      st_other
                         .symtab::00000066 01 00                   dw           1h                      st_shndx
                         .symtab::00000068 5c 01 21 00 00 00 00 00 dq           21015Ch                 st_value
                         .symtab::00000070 00 00 00 00 00 00 00 00 dq           0h                      st_size

Why are the db, dw, ddw, dq mnemonics used here?

Would not it be more natural to have GNU_As-native pseudo-ops:

.zero X //X = Amount of null bytes to write
.byte X //X = byte amount to write (0x00 thru 0xFF Hex range; 0 thru 255 decimal range)
.hword X X = halfword amount to write (hex range 0x0000 thru 0xFFFF, decimal range 0 thru 65535)
.short X //Same as .hword
.word 0xXXXXXXXX //X = Word value to write
.long 0xXXXXXXXX //Same as .word
.xword 0xXXXXXXXXXXXXXXXX //X = Doubleword value to write
.float X //X = decimal value for single precision float, takes up one Word of memory
.single X //Same as .float
.double X //X = decimal value for double precision float, takes up two Words of memory
.string "write text here" //Writes out a typical 8-bit ASCII string that is auto appended with a Null byte
.asciz "write text here" //Same as .string
.ascii "write text here" //Writes out a 8-bit ASCII string !!!WITHOUT!!! the null byte appended.

The naive loop code is decompiled as:

                             //
                             // .text 
                             // SHT_PROGBITS  [0x210158 - 0x210188]
                             // ram:00210158-ram:00210188
                             //
                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                               undefined entry()
             undefined         <UNASSIGNED>   <RETURN>
                              _start                                          XREF[4]:     Entry Point(*), 00200018(*), 
                              entry                                                        002000c0(*), 
                                                                                           _elfSectionHeaders::00000050(*)  
                         00210158 13 00 80 d2               mov                            x19,#0x0
                              loop                                            XREF[1]:     00210178(j)  
                         0021015c 20 00 80 d2               mov                            x0,#0x1
                         00210160 41 01 08 30               adr                            x1,0x220189
                         00210164 c2 01 80 d2               mov                            x2,#0xe
                         00210168 08 08 80 d2               mov                            x8,#0x40
                         0021016c 01 00 00 d4               svc                            0x0
                         00210170 73 06 00 91               add                            x19,x19,#0x1
                         00210174 7f 2a 00 f1               cmp                            x19,#0xa
                         00210178 21 ff ff 54               b.ne                           loop
                         0021017c 00 00 80 d2               mov                            x0,#0x0
                         00210180 a8 0b 80 d2               mov                            x8,#0x5d
                         00210184 01 00 00 d4               svc                            0x0
                         00210188 fe                        undefined1                     FEh

Do the last .byte 0xFE is disassembled as undefined1, not as db, whereas in the .data section it is disassembled as

                              mylabel
                         00220197 ff                        ??                             FFh

well, ?? is even less specific than undefined1. Perhaps a .byte 0xFE and .byte 0xFF would have made more sense?

[pelrun]

Ghidra is independent of any particular ISA or assembler. So what you consider "natural" may make no sense for a different platform binary. But you're talking about raw data, not disassembly, so that's even further removed.

What you get is Ghidra's base type annotations. And there's a key semantic difference between "db", which is simply 8 bits with no information about how it's interpreted (and in fact may just be part of a longer type), and "byte", "char" or "undefined1", which imply that there's some interpretation information present - yes, even "undefined1", because that means a 1-byte wide reference to that location was found from code, but there isn't enough information to infer a stronger type.

?? is even less information than "db", because it means no information has been applied to that memory location at all, not automatically and not manually.