[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094

John F. Carr <jfc@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfc@mit.edu

--- Comment #9 from John F. Carr <jfc@mit.edu> ---
The problem is introduced in the process of turning the .o into a .ko.
Pinpointing the bug requires study of the exact definition of the ARM
relocation types, in assembly and in ELF.

If you change -c to -S in the command for building cc_htcp.o you get two
consecutive lines of assembly

        adrp    x11, :got:vnet_entry_htcp_adaptive_backoff
        ldr     x11, [x11, :got_lo12:vnet_entry_htcp_adaptive_backoff]

In cc_htcp.o these become (objdump --disassemble --reloc)

 200:   9000000b        adrp    x11, 0 <htcp_mod_init>
                        200: R_AARCH64_ADR_GOT_PAGE    
vnet_entry_htcp_adaptive_backoff
 204:   f940016b        ldr     x11, [x11]
                        204: R_AARCH64_LD64_GOT_LO12_NC
vnet_entry_htcp_adaptive_backoff

In cc_htcp.ko these are incorrectly optimized after the linker determines the
variable is close to the instruction:

   10f50:       d503201f        nop
   10f54:       10082f6b        adr     x11, 21540
<vnet_entry_htcp_adaptive_backoff>

This computes the address of the value instead of loading the value.  The
optimization would be correct if there were an adrp+adr pair but it is not
correct for adrp+ld.  So is :got_lo12: the wrong prefix, is
R_AARCH64_LD64_GOT_LO12_NC the wrong binary relocation code, or did the linker
forget to check the opcode of the instruction it rewrote?

-- 
You are receiving this mail because:
You are on the CC list for the bug.