This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Introduce <elf-initfini.h> and ELF_INITFINI for all architectures
* Florian Weimer:
> * Jim Wilson:
>
>> On Thu, Feb 20, 2020 at 10:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>>> That's because libc.so.6 still has DT_INIT, from which _environ and
>>> other variables are set up. I assumed binutils would convert that into
>>> DT_INITARRAY because the architecture is not supposed to have DT_INIT.
>>> Without that, it's hard to declare that there is no DT_INIT, and the
>>> patch essentially breaks ABI (because DT_INIT processing is gone).
>>
>> DT_INIT is a function address. DT_INITARRAY is a pointer to a table
>> of addresses. I don't see how the linker can easily convert between
>> them. We would have to increase the size of the init_array table at
>> link time, and I don't think we have any linker support for that.
>> Maybe we could modify the startfiles to put a weak reference to _init
>> at the end of init_array, right before the zero that normally ends the
>> list, and fix the linker to stop creating DT_INIT for _init. But that
>> sounds a little risky, and defeats the purpose of dropping support for
>> _init to reduce code size. I would prefer that glibc not create an
>> _init function in the first place.
>
> I'm not worried about glibc here. It's easy to make glibc consistent
> with itself. The patch I posted seems to do the trick, without
> regressing anywhere else.
>
> What I don't know is whether this binutils bug has resulted in DT_INIT
> being used *elsewhere*. I don't have a RISC-V distribution to analyze,
> so I really don't know. Fedora RISC-V seems dead, this hasn't been
> updated in a while:
>
> <https://dl.fedoraproject.org/pub/alt/risc-v/repo/fedora/rawhide/latest/riscv64/>
>
> (I have existing tools for RPM-based distributions, so having one would
> be most useful to me to check for DT_INIT references.)
I loaded the repository
<http://fedora.riscv.rocks/repos/rawhide/latest/riscv64/>
and ran this query:
SELECT symboldb.nevra(package), file.name
FROM symboldb.elf_dynamic dt
JOIN symboldb.elf_file hdr USING (contents_id)
JOIN symboldb.file USING (contents_id)
JOIN symboldb.package USING (package_id)
WHERE hdr.e_machine = 243 AND dt.tag = 12 ORDER BY 1, 2;
nevra | name
-----------------------------------------------+----------------------------------------------------
glibc-2.30.9000-31.fc32.riscv64 | /lib64/libc-2.30.9000.so
jamin-0.97.16-19.20111031cvs.fc31.riscv64 | /usr/lib64/ladspa/jamincont_1912.so
ladspa-1.13-23.fc31.riscv64 | /usr/lib64/ladspa/amp.so
ladspa-1.13-23.fc31.riscv64 | /usr/lib64/ladspa/delay.so
ladspa-1.13-23.fc31.riscv64 | /usr/lib64/ladspa/filter.so
ladspa-1.13-23.fc31.riscv64 | /usr/lib64/ladspa/noise.so
ladspa-autotalent-plugins-0.2-20.fc31.riscv64 | /usr/lib64/ladspa/autotalent.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/adsr_1653.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/adsr_1680.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/amp_1654.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/blop_files/parabola_1649_data.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/blop_files/sawtooth_1641_data.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/blop_files/square_1643_data.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/branch_1673.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/dahdsr_2021.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/difference_2030.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/fmod_1656.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/interpolator_1660.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/lp4pole_1671.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/product_1668.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/pulse_1645.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/quantiser100_2029.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/quantiser20_2027.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/quantiser50_2028.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/random_1661.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/ratio_2034.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sawtooth_1641.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sequencer16_1677.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sequencer32_1676.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sequencer64_1675.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/square_1643.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sum_1665.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sync_pulse_2023.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/sync_square_1678.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/tracker_2025.so
ladspa-blop-plugins-0.2.8-26.fc31.riscv64 | /usr/lib64/ladspa/triangle_1649.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_autopan.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_chorusflanger.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_deesser.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_doubler.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_dynamics_m.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_dynamics_st.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_echo.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_eq.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_eqbw.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_limiter.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_pinknoise.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_pitch.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_reflector.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_reverb.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_rotspeak.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_sigmoid.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_tremolo.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_tubewarmth.so
ladspa-tap-plugins-0.7.0-24.fc31.riscv64 | /usr/lib64/ladspa/tap_vibrato.so
ladspa-wasp-plugins-0.9.7-10.fc31.riscv64 | /usr/lib64/ladspa/libwasp_booster.so
ladspa-wasp-plugins-0.9.7-10.fc31.riscv64 | /usr/lib64/ladspa/libwasp_noisifier.so
ladspa-wasp-plugins-0.9.7-10.fc31.riscv64 | /usr/lib64/ladspa/libwasp_xshaper.so
nekobee-dssi-0.1.7-22.fc31.riscv64 | /usr/lib64/dssi/nekobee.so
numactl-libs-2.0.12-3.fc32.riscv64 | /usr/lib64/libnuma.so.1.0.0
sblim-cmpi-rpm-1.0.1-25.fc31.riscv64 | /usr/lib64/libcimrpm.so.0.0.0
sblim-cmpi-rpm-1.0.1-25.fc31.riscv64 | /usr/lib64/libcimrpmv4.so.0.0.0
(62 rows)
So there are a few packages which have been built in such a way that
they have a DT_INIT tag.
I don't know if this qualifies as use, and I haven't disassembled the
objects to see if the init routine does anything meaningful.
Thoughts? Should we still label RISC-V as an !ELF_INITFINI
architecture?
Thanks,
Florian