[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Victor Do Nascimento changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Victor Do Nascimento changed: What|Removed |Added Status|ASSIGNED|WAITING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #6 from Victor Do Nascimento --- Proposed fix submitted: https://sourceware.org/pipermail/binutils/2024-April/133638.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #5 from Victor Do Nascimento --- (In reply to Nick Clifton from comment #4) Hi Nick, > In my opinion, the disassembler should never trigger an abort (or an > assertion), even if it is being asked to decode an illegal bit sequence. > Instead it should just display the bits with an annotation that they are > illegal. In fact when a user is disassembling with the -D/--disassemble-all > it should be clear that they expect illegal bit sequences to be encountered, > and objdump should really be able to cope. Agreed. > (This also goes back to my long standing opinion that library functions > should never call abort. Instead they should always report back to their > caller that they have encountered some kind of problem, and allow the caller > to decide what to do). > > My suggestion is that you change get_sreg_qualifier_from_value() so that it > returns AARCH64_OPND_QLF_NIL if it encounters an error. (Or maybe a new > aarch64_opnd_qualifier value such as AARCH64_OPND_QLF_ERR). And then update > the callers of get_sreg_qualifier_from_value to take some kind of action if > this result is returned. A bit if a hassle I know, but I think that it is > the right thing to do. Thanks for the suggestion, it'll come in handy. I do agree it's the right course of action to take. cheers, Victor > Cheers > Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #4 from Nick Clifton --- (In reply to Victor Do Nascimento from comment #3) Hi Victor, > Looking at `readelf -S ./libc.so.6', we see that the crash happens within > the .gnu.hash section of the elf file. This, combined with the fact we used > the -D flag when disassembling leads me to the conclusion that we're trying > to disassemble non-instruction bytes, which due to ill-luck, look an awful > lot like a valid instruction. Ah - that makes sense. > This thus seems like a quality of implementation issue. Normal disassembly > of executable sections of code appear to be functioning correctly, but I > guess a rethink is needed in terms of how assertions are used in disassembly. > > My impression is that their use in a context such as in the use of `objdump > --disassemble-all` ought be predicated on whether or not we're disassembling > in a strictly executable code-only section of the object file or not... In my opinion, the disassembler should never trigger an abort (or an assertion), even if it is being asked to decode an illegal bit sequence. Instead it should just display the bits with an annotation that they are illegal. In fact when a user is disassembling with the -D/--disassemble-all it should be clear that they expect illegal bit sequences to be encountered, and objdump should really be able to cope. (This also goes back to my long standing opinion that library functions should never call abort. Instead they should always report back to their caller that they have encountered some kind of problem, and allow the caller to decide what to do). My suggestion is that you change get_sreg_qualifier_from_value() so that it returns AARCH64_OPND_QLF_NIL if it encounters an error. (Or maybe a new aarch64_opnd_qualifier value such as AARCH64_OPND_QLF_ERR). And then update the callers of get_sreg_qualifier_from_value to take some kind of action if this result is returned. A bit if a hassle I know, but I think that it is the right thing to do. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #3 from Victor Do Nascimento --- So a trivial reproducer for the reported issue would be attempting to disassemble `.inst 0x9dc39839'. Looking at `readelf -S ./libc.so.6', we see that the crash happens within the .gnu.hash section of the elf file. This, combined with the fact we used the -D flag when disassembling leads me to the conclusion that we're trying to disassemble non-instruction bytes, which due to ill-luck, look an awful lot like a valid instruction. Only problem is, it differs from the relevant valid instruction by a combination of three bits which would encode an invalid operand qualifier. We thus get far enough into the disassembly of those 32 bits that objdump doesn't know it should display undef or similar. This thus seems like a quality of implementation issue. Normal disassembly of executable sections of code appear to be functioning correctly, but I guess a rethink is needed in terms of how assertions are used in disassembly. My impression is that their use in a context such as in the use of `objdump --disassemble-all` ought be predicated on whether or not we're disassembling in a strictly executable code-only section of the object file or not... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |victorldn at sourceware dot org Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Victor, Thanks very much for taking a look at this. :-) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Victor Do Nascimento changed: What|Removed |Added CC||victorldn at sourceware dot org --- Comment #1 from Victor Do Nascimento --- I've managed to replicate the bug encountered attempting to generate the objdump on glibc-2.39.9000-10.fc41.aarch64.rpm. I'm deciphering what the assembly instruction would have been that is encoded by those particular 32 bits which give rise to the error in question. Comparing to the valid RCPC3 instructions, the combination of bits found in FLD_rcpc3_size and FLD_opc1 in the 2646841401 decimal value is not valid, so it seems to me that the disassembler is right to complain. Something is therefore fishy somewhere in the assembly. Will post more findings as I get them. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Nick Clifton changed: What|Removed |Added Version|unspecified |2.43 (HEAD) -- You are receiving this mail because: You are on the CC list for the bug.
