From nobody Wed Apr 26 10:55:02 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5wkR12FSz47ps4 for ; Wed, 26 Apr 2023 10:55:11 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5wkQ4kChz3kFn; Wed, 26 Apr 2023 10:55:10 +0000 (UTC) (envelope-from hselasky@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D3DE2261CF7; Wed, 26 Apr 2023 12:55:01 +0200 (CEST) Message-ID: <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> Date: Wed, 26 Apr 2023 12:55:02 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Link modules to DYN type To: Zhenlei Huang , FreeBSD CURRENT Cc: Gleb Smirnoff References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> Content-Language: en-US From: Hans Petter Selasky In-Reply-To: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Q5wkQ4kChz3kFn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/26/23 12:36, Zhenlei Huang wrote: > Hi, > > I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet sysctl variables be loader tunable), > the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not those to `sys/kern/link_elf.c` . > > After some hacking I realized that `link_elf.c` is for EXEC (Executable file) or DYN (Shared object file), and `link_elf_obj.c` is > for REL (Relocatable file). > > ``` > /* link_elf.c */ > static int > link_elf_load_file(linker_class_t cls, const char* filename, > linker_file_t* result) > { > ... > if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN) { > error = ENOSYS; > goto out; > } > ... > } > > > /* link_elf_obj.c */ > static int > link_elf_load_file(linker_class_t cls, const char *filename, > linker_file_t *result) > { > ... > if (hdr->e_type != ET_REL) { > error = ENOSYS; > goto out; > } > ... > } > ``` > > Run the following snip: > ``` > # find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type > ``` > shows that all the kernel modules' types are `REL (Relocatable file)`. > > I guess if some module such as if_bridge is linked to DYN type, then I can do runtime for the changes to `sys/kern/link_elf.c`. > > I'm not familiar with elf and linkers, is that ( compile module and link it to DYN type ) possible ? > Hi, I don't have an answer for you either, but I have seen in the past, loading kernel modules behaves a bit like libraries, in the following regard: If two kernel modules define the same global symbol, then no warning is given and the first loaded symbol definition (I think) is used to resolve that symbol for all kernel modules, regardless of the prototype. Probably we should not allow this. That's why building LINT is a good thing, to avoid this issue. Even if we don't have C++ support in the FreeBSD kernel, defining symbol names the way C++ does for C could be nice for the kernel too, also with regards to debugging systems. Many times when I don't know what is going on, I do like this: #include .... if (not too fast or my sysctl debug) { printf("My tracer\n"); kdb_backtrace(); } Dtrace can also do this, but not during boot. Just track who is calling those functions, and you'll probably find the answer to your question! --HPS > > Best regards, > Zhenlei >