cyyself

#!/usr/bin/env python3

PREFIX = "2001:470:19:a65:"
SUFFIX = "/64"
LEN = 14

print("brctl addbr pathgen")
print("ip link set pathgen up")
print("ip addr add %sffff:ffff:ffff:ffff%s dev pathgen" % (PREFIX, SUFFIX))

cyyself

#!/usr/bin/env sh
# Check if multiple IPv6 addresses are assigned to the usb0 interface
# If so, we have deprecated addresses and need to restart the interface.
if [ $(cat /proc/net/if_inet6 | grep usb0 | wc -l) -gt 2 ]; then
    ifdown wwan6
    ifup wwan6
fi

cyyself

#!/usr/bin/env sh

wg_filter="wg0 wg1" # EDITME

current_time=$(date +%s)
wg show all dump | awk '{if ($5 != "off") print $1,$6}' | while read -r each_dump; do
    interface=$(echo $each_dump | cut -d' ' -f1)
    last_handshake=$(echo $each_dump | cut -d' ' -f2)
    if echo $wg_filter | grep -q $interface; then
        if [ $((current_time - last_handshake)) -gt 240 ]; then

cyyself

# ip-full kmod-veth iptables-nft ip6tables-mod-nat ip6tables-nft
ip6tables -t nat -A POSTROUTING -s fd05::1/64 -j MASQUERADE
ip link add 5g_lan type veth peer 5g_lan_peer
ip netns add 5g_lan
ip link set dev 5g_lan_peer netns 5g_lan
ip netns exec 5g_lan sh <<EOF
    sysctl -w net.ipv4.conf.all.forwarding=1
    sysctl -w net.ipv6.conf.all.forwarding=1
    ip link set dev lo up
    ip link set dev 5g_lan_peer up

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},