[Bug gas/31326] SCFI must handle non QWORD ALU with imm and MOV ops correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=31326 --- Comment #1 from Sourceware Commits --- The master branch has been updated by Indu Bhagat : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f8c50ae2703e6b67655b13b9766365ae3073fd15 commit f8c50ae2703e6b67655b13b9766365ae3073fd15 Author: Indu Bhagat Date: Tue Feb 6 16:20:53 2024 -0800 gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly PR gas/31326 SCFI must handle non QWORD ALU with imm and MOV ops correctly As per the x86 ISA manual: - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register. - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the destination general-purpose register are not modified by the operation. Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have implications on SCFI. SCFI/ginsn machinery does not track operation size in the ginsn representation. But given that these sub-QWORD ops update only a portion of a 64-bit destination register, for SCFI purposes, this needs to be deemed as an untraceable update (when the destination is REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected for stack management, but the SCFI machinery must behave correctly, when such ops are indeed present. As mentioned earlier, ginsn representation does not carry operation size information. To resolve the issue raised in PR gas/31326, an option is to force the generation of GINSN_TYPE_OTHER for all cases when there is a 8/16/32 bit op. But this may dilute the utility of ginsn for other use-cases, when they pop up in future. The current approach is less disruptive than above in that it generates GINSN_TYPE_OTHER for all cases only when: - there is a 8/16/32 bit op, and - the 64-bit op is otherwise traceable. In other words this means: - For add/sub ops where dest is reg and src is reg/mem: these always make dest reg untraceable; So, the current handling is unchanged. We simply skip detecting 8/16/32-bit ops. - An x86 pop instruction is translated to a load ginsn followed by a stack increment add op. A load op always makes dest reg untraceable. Hence, if the pop instruction is sub-QWORD, we continue to (skip detecting 8/16/32-bit op, and) generate the load instruction as usual. This means that if input asm does have save and restore of unequal sized registers, gas/SCFI will not detect nor warn. - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated when a 8/16/32-bit op is seen. gas/ PR gas/31326 * config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code comment. (x86_ginsn_addsub_mem_reg): Likewise. (x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early. (x86_ginsn_move): Likewise. (x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in opcode_space SPACE_BASE) about skipped handling. gas/testsuite/: PR gas/31326 * gas/scfi/x86_64/ginsn-add-1.l: Update. * gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops. * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update. * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of add to invoke and test the ginsn_dw2_regnum code path. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31346] [gp-display-text] For functions and methods show the level in the call stack in the relevant views
https://sourceware.org/bugzilla/show_bug.cgi?id=31346 Ruud van der Pas changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31347 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31347] [gp-display-text] Support a filter to select call stacks for a target function at a specified level
https://sourceware.org/bugzilla/show_bug.cgi?id=31347 Ruud van der Pas changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31346 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31347] [gp-display-text] Support a filter to select call stacks for a target function at a specified level
https://sourceware.org/bugzilla/show_bug.cgi?id=31347 Ruud van der Pas changed: What|Removed |Added CC||ruud.vanderpas at oracle dot com Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31347] New: [gp-display-text] Support a filter to select call stacks for a target function at a specified level
https://sourceware.org/bugzilla/show_bug.cgi?id=31347 Bug ID: 31347 Summary: [gp-display-text] Support a filter to select call stacks for a target function at a specified level Product: binutils Version: 2.42 Status: NEW Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- This is related to bugzilla #31346. Once the functionality requested in this RFE is available, it will be useful to have a filter that allows the user to show the call stacks for a target function at a specific level in the call stack. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31346] [gp-display-text] For functions and methods show the level in the call stack in the relevant views
https://sourceware.org/bugzilla/show_bug.cgi?id=31346 --- Comment #1 from Ruud van der Pas --- This definitely sounds like a useful addition we will consider. We need to decide how to make this information available. This should also be in such a way that the gprofng tools that make use of gp-display-text, like the GUI, can easily access this information and make it available to the user. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31346] [gp-display-text] For functions and methods show the level in the call stack in the relevant views
https://sourceware.org/bugzilla/show_bug.cgi?id=31346 Ruud van der Pas changed: What|Removed |Added CC||ruud.vanderpas at oracle dot com Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31346] New: [gp-display-text] For functions and methods show the level in the call stack in the relevant views
https://sourceware.org/bugzilla/show_bug.cgi?id=31346 Bug ID: 31346 Summary: [gp-display-text] For functions and methods show the level in the call stack in the relevant views Product: binutils Version: 2.42 Status: NEW Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- This is a request from a Java development team: "In the Functions, Callers - Callees and CallTree view, when you click on a method name, or node to also show at what level or number in the depth of the stack trace that method or node is. The idea is to show the user is this stack 300 deep, and is the method / node I just clicked on number 153 of 300? Or more generally display in some means that value the numeric stack depth of the currently selected method or node, and maybe the total depth of that stack trace." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 --- Comment #4 from Maciej W. Rozycki --- Yes, it has to be a warning or error for PIC/PIE (whatever the BFD policy is here; I don't remember offhand). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 --- Comment #3 from YunQiang Su --- (In reply to YunQiang Su from comment #2) > Thank you so much. I understand it now: It is used to branch to an absolute > address with branch instructions. > > So it should never be used for PIC/PIE code? (if we want to add a more > dynamic relocation) > Sorry, typo: if we do *not* want ... > I think that we can emit an error if it is used for PIC code. > > For LLVM, let's disable this feature for current: the behavior of LLVM is > different with gas. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 --- Comment #2 from YunQiang Su --- Thank you so much. I understand it now: It is used to branch to an absolute address with branch instructions. So it should never be used for PIC/PIE code? (if we want to add a more dynamic relocation) I think that we can emit an error if it is used for PIC code. For LLVM, let's disable this feature for current: the behavior of LLVM is different with gas. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 --- Comment #1 from Maciej W. Rozycki --- The handling of R_MIPS_PC16 is correctly specified in the MIPS psABI to overflow at link time where applicable, so if the linker finds the value calculated for the symbol referred (whether it's absolute or not does not matter) not to fit in the field relocated, it is supposed to report it as with other such issues, which BFD correctly does (taking a less trivial example): $ cat b.s .text .globl foo .entfoo foo: b 0x1234 .endfoo $ as -32 -o b.o b.s $ ld -Ttext=0x8000 -efoo -melf32btsmip -o b b.o b.o: in function `foo': (.text+0x0): relocation truncated to fit: R_MIPS_PC16 against `*UND*' $ Use -Werror, as any sane project should do, to catch such issues. There is an issue however with absolute symbol processing (and possibly with any addend processing) with REL relocations here: $ as -32 -o b-32.o b.s $ ld -Ttext=0 -efoo -melf32btsmip -o b-32 b-32.o $ as -n32 -o b-n32.o b.s $ ld -Ttext=0 -efoo -melf32btsmipn32 -o b-n32 b-n32.o $ objdump -dr b-32.o b-n32.o b-32.o: file format elf32-tradbigmips Disassembly of section .text: : 0: 1919b 2468 0: R_MIPS_PC16 *ABS* 4: nop ... b-n32.o: file format elf32-ntradbigmips Disassembly of section .text: : 0: 148db 1238 0: R_MIPS_PC16 *ABS*+0x1230 4: nop ... $ objdump -d b-32 b-n32 b-32: file format elf32-tradbigmips Disassembly of section .text: : 0: 1919b 2468 4: nop ... b-n32: file format elf32-ntradbigmips Disassembly of section .text: : 0: 148cb 1234 4: nop ... $ Notice how the absolute value is not correctly referred in the o32/REL variant, due to how it has been incorrectly encoded for the in-place case. Of course for PIC/PIE links this calculation is supposed to always fail for absolute symbols, because there is no corresponding dynamic relocation defined in the MIPS psABI to fulfil the purpose of the calculation at load time. However it does not happen right now, which is a bug in LD. $ ld -shared -efoo -melf32btsmip -o b.so b.o $ readelf -r b.so There are no relocations in this file. $ In the absence of a dynamic relocation (which for text is a no-no anyway) the resulting DSO will only correspond to the original source code if it has been loaded such that `foo' has the run-time value of 0, which of course cannot be guaranteed. Therefore this link is expected to fail. So it appears we have two issues in absolute symbol processing with R_MIPS_PC16 relocations, neither of which affects your case though. NB I find it odd for someone to actually use an absolute value with a branch in their project, though technically it's of course defined if a bit unusual a case in terms of the MIPS psABI. The bugs observed only confirm it's an odd corner case hardly anyone cares about. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31323] [x86] GAS does not error out instruction that exceed 15 bytes
https://sourceware.org/bugzilla/show_bug.cgi?id=31323 --- Comment #4 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0afc614c9938fbf5eda10a26c77d574c3c2f945a commit 0afc614c9938fbf5eda10a26c77d574c3c2f945a Author: H.J. Lu Date: Mon Feb 5 11:58:08 2024 -0800 x86: Warn .insn instruction with length > 15 bytes Change .insn instruction with length > 15 bytes from error to warning. PR gas/31323 * config/tc-i386.c (output_insn): Issue a warning when .insn instruction length exceeds the limit of 15 bytes. * testsuite/gas/i386/oversized64.s: Add a test for .insn * testsuite/gas/i386/oversized64.l: Updated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 YunQiang Su changed: What|Removed |Added CC||macro at orcam dot me.uk, ||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31343] New: MIPS: correct behavior of branch to an imm?
https://sourceware.org/bugzilla/show_bug.cgi?id=31343 Bug ID: 31343 Summary: MIPS: correct behavior of branch to an imm? Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: syq at debian dot org Target Milestone: --- Some code like: b (0) generates the binary like: <.text>: 0: 1000 b 0x0 0: R_MIPS_PC16 *ABS* 4: nop It will cause something wrong during runtime, normally, jump to an address like 0xABCD. https://github.com/llvm/llvm-project/issues/67951 Should we just emit an error for the asm code like this, or emit binary without relocations? How should we treat the IMM: may be how many bytes? -- You are receiving this mail because: You are on the CC list for the bug.
