Date: Sat, 5 Mar 2011 11:48:54 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-stable@freebsd.org Subject: Re: Linker set issues with ath(4) HALs Message-ID: <20110305094854.GM78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110305085004.GA70142@server.vk2pj.dyndns.org> References: <20110305085004.GA70142@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--M0Yq1Q+lJysaJ3ln
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Mar 05, 2011 at 07:50:05PM +1100, Peter Jeremy wrote:
> I have a Atheros AR5424 and so, based on the 8.2-STABLE i386 NOTES
> and some rummaging in the sources, I tried to build a kernel with:
>=20
> device ath # Atheros pci/cardbus NIC's
> device ath_ar5212 # HAL for Atheros AR5212 and derived chips
> device ath_rate_sample # SampleRate tx rate control for ath
>=20
> and this died during the kernel linking with:
> linking kernel.debug
> ah.o(.text+0x23c): In function `ath_hal_rfprobe':
> /usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_se=
t_ah_rf
> s'
> ah.o(.text+0x241):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined refere=
nce to `__stop_set_ah_rfs'
> ah.o(.text+0x25a):/usr/src/sys/dev/ath/ath_hal/ah.c:142: undefined refere=
nce to `__stop_set_ah_rfs'
>=20
> Following a suggestion by a friend, I changed that to:
>=20
> device ath # Atheros pci/cardbus NIC's
> options AH_SUPPORT_AR5416
> device ath_hal # Atheros HAL
> device ath_rate_sample # SampleRate tx rate control for ath
>=20
> and it worked. Normally, I would leave it at that but I'd like to
> understand what is actually going on...
>=20
> In both cases, ah.o contains the following 4 references:
> U __start_set_ah_chips
> U __start_set_ah_rfs
> U __stop_set_ah_chips
> U __stop_set_ah_rfs
> generated by:
> /* linker set of registered chips */
> OS_SET_DECLARE(ah_chips, struct ath_hal_chip);
> /* linker set of registered RF backends */
> OS_SET_DECLARE(ah_rfs, struct ath_hal_rf);
>=20
> These symbols do not appear in any other .o files, though there are a
> variety of other __{start,stop}_set_* symbols - all of which show up
> as 'A' (absolule) values in the final kernel.
>=20
> My questions are:
> How are these linker set references resolved? I can't find anything
> that defines these symbols - either in .o files or in ldscript files.
>=20
> In the first case, there are 2 pairs of undefined linker set variables
> but the linker only reports one pair as unresolved. Why don't both
> sets show up as resolved or unresolved? Why does using the generic
> "ath_hal", rather than the hardware-specific HAL fix the problem?
Linker synthesizes the symbols assuming the following two conditions are
met:
- the symbols are referenced;
- there exists an ELF section named `set_ah_rfs'.
It assigns the (relocated) start of the section to __start_<sectionname>,
and end to __stop_<sectionname>.
Most likely, omitting the option causes some SET_ENTRY() macro, which put
a symbol into linker set, to be ommitted. Then, no section is created
and linker does not synthesizes the missed symbols.
--M0Yq1Q+lJysaJ3ln
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk1yBwUACgkQC3+MBN1Mb4htQgCgtjZZsrmuhJ6qcQEGmtySwJv1
acsAoO39NeYz3lDohvc4ftEHLOCbh2dE
=7ihQ
-----END PGP SIGNATURE-----
--M0Yq1Q+lJysaJ3ln--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110305094854.GM78089>