Re: [PATCH] RISC-V: Fix TLS and --gc-sections conflict.

[Jim Wilson <jimw at sifive dot com>]

On Tue, Oct 2, 2018 at 2:51 AM Andreas Schwab <schwab@suse.de> wrote:
> On Aug 02 2018, Jim Wilson <jimw@sifive.com> wrote:
> > It gets merged into .tdata, which still gets optimized away if empty at the
> > end.
>
> Does it?  I don't see that happening.  The linker now always generates a
> .tdata section, moreover with the wrong type NOBITS if empty.

Apparently not, as I can see it in a testcase now.  Not sure where I
made the mistake.  But does this cause any actual problems?  I didn't
see any problems with my gcc testsuite run.  It is target independent
code that is setting the .tdata section to NOBITS when empty.  So that
part doesn't seem to be a problem with the RISC-V code.  Is there some
reason why this is wrong?  I do see that we have an empty PT_TLS
segment.  Maybe there is a performance issue here with doing extra
unnecessary work at load time?

As far as I know, RISC-V is the only target with copy relocs against
thread data which is the ultimate cause of this problem.   This means
tdata sections may not work exactly the same as other targets, and we
might need changes to target independent code in bfd to improve this.
But I don't think that my earlier patch is wrong, as it is fixing gcc
testsuite failures with --gc-sections.  I probably need to spend some
time studying bfd and see if I can find a way to delete an empty tdata
section when there are no copy relocs.  Maybe I can strip the
tdata.dyn section in elfnn-riscv.c when it is zero size.  Or maybe I
can change where it is created, so that it is only created when
non-zero.  I will take a look at this.

Still, it would be nice to know exactly why this is wrong.

Jim