cyyself

We can trust the use of _dl_lookup_symbol_x during elf_machine_runtime_setup in SHARED is safe

Prove

These discussions are based on recent glibc commit a4c414796a.

I know it's hard to prove _dl_lookup_symbol_x being called at elf_machine_runtime_setup without l_relocated == 1 when we have #ifdef SHARED is safe. But if we trust another place it is being called is safe, and there is no change for the requested data structure between these 2 times , then it's natural to trust we call it here is safe.

We can prove this by debugging lib/ld-linux-riscv64-lp64d.so.1 in gdb. First, compile glibc commit a4c414796a with && l->l_relocated removed in sysdeps/riscv/dl-machines.h.

cyyself

Related

issue: https://github.com/flatpak/xdg-desktop-portal/issues/1032

Error log:

➜  ~ systemctl --user status xdg-desktop-portal
● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
     Active: activating (start) since Tue 2024-11-26 12:41:59 CST; 1min 5s ago

cyyself

#!/usr/bin/env python3

import sys
from pathlib import Path

def read_csv(file_path: Path):
    filename = file_path.name
    with open(file_path, 'r') as file:
        lines = file.readlines()
    result_line_idx = lines.index('"Selected Results Table"\n')

cyyself

# This is a sample config file for CPU2006. It was tested with:
#
#      Compiler name/version:       [gcc, g++, gfortran 4.3.4]
#                                   [gcc, g++, gfortran 4.4.4]
#                                   [gcc, g++, gfortran 4.6.0]
#      Operating system version:    [SLES 11 SP1, 64-bit, gcc 4.3.4 and 4.6.0]
#                                   [RHEL 6, 64-bit, gcc 4.4.4]
#      Hardware:                    [Opteron]
#
# If your platform uses different versions, different

cyyself

A function clone may prevent GCC from inlining a callee into the caller.

I noticed this when testing target_clones features for performance tuning.

Tested GCC version: GCC 14.2 and GCC master commit 1de156eb2bb445cd0e0a582944dcd75d085f30c9 on both x86-64 and RISC-V target.

A example is shown below:

git clone https://github.com/eembc/coremark.git

cyyself

/* Types for recording extension to RISC-V C-API bitmask.  */
struct riscv_ext_bitmask_table_t {
  const char *ext;
  int groupid;
  int bit_position;
};

static const riscv_ext_bitmask_table_t riscv_ext_bitmask_table[] =
{
  {"a",           0,  0},

cyyself

good:

__attribute__((target("default")))
int foo(int *arr) {
    int sum = 0;
    for (int i=0;i<16;i++) sum += arr[i];
    return sum;
}

cyyself

cycles:u -> r22:u
instructions:u -> r4d:u

cyyself

#include <stdio.h>


char __attribute__ ((noinline)) foo() {
	return -1;
}

int main() {
	char ret;
	ret = foo();

cyyself

LLVM: 66e03eda42e1cd6d8e89d13876a44852815efb71
XiangShan: 136f64975e337409416bed849b58026e7085d758
Verilator: 0a9b31bb30fd604ff68854290cc5cc90e7dfd172
QEMU: ddcfe49ed38ebd2a659c53f9dcecf7e33899b29d
PGO: -fprofile-instr-generate (on X86 Host)

rv64gc_zba_zbb_zbc_zbc_zicond:
cpu 0 insns: 1741983881730
     Branch: 103964378641
   Br Taken: 93664761377