Michael Matz wrote:
Hello grischka,
I had to revert a small part of your da8c62 commit ("various stuff"):
tccasm.c:
- keep forward asm labels static, otherwise they will endup
in dynsym eventually.
A symbol which stays undefined until the end is implicitely
STB_GLOBAL, even without a .globl directive. I've added a testcase to
that effect. Before just reverting the hunk I've tried to move it
somewhere else in order not to lose the effect mentioned above.
But in the end I wasn't really successful in constructing a testcase
where such symbol ends up in dynsym when it shouldn't. E.g. local
labels (the numeric ones) are always already constructed as
VT_STATIC. And normal labels are also created VT_STATIC, except if
they already were associated with a .globl directive. So I don't
really see how the problem above could have happened.
To recollect, give the following assembler snippet:
jmp 1f
local:
call local
call undefined
call global
.globl global
global:
1: nop
the symbols L..1 and local need to be STB_LOCAL, while undefined and
global need to be STB_GLOBAL.
So, if you have a testcase or remember the situation that you tried to
fix, can you tell me which one it was? :)
Yes. The long story is:
I was messing with Alpine/musl, which prefers relocatable executables,
for which to produce I have a patch which basically is no big deal
(just going the OUTOUT_DLL path and adding some aspects of exes).
But..., of course then musl doesn't like to see DT_TEXTREL in such
executables (or dll's either).
So I did not commit this patch for now (because I didn't really have
the intention to add full PIC support maybe for all platforms). However
I made it so that DT_TEXTREL is set only when needed.
Now, since x86_64 supports pc-relative data addresses, at least
for tcc itself it is possible to avoid DT_TEXTREL (and hence to
create a fully musl compliant relocatable tcc executable if wanted).
Except ... there was one text relocation which at first I could not
explain where it comes from but then with some objdumps I found it
was a relocation to the 'p3' label in libtcc1.a:alloca86_64.s which
defeated my efforts to get rid of DT_TEXTREL (at least for a self-
compiled tcc at least on x86_64, that is). See here
/* alloca86_64.S */
.globl alloca
alloca:
pop %rdx
...
jz p3
...
p3:
push %rdx
ret
Now I would think that 'p3' neither is global nor is undefined and
therefor should not be placed in dynsym and even less with a non-pc-
relative relocation. The only thing that is particular about p3
(say in contrast to p1 and p2) is that it is a forward label.
Sorry for messing up your test cases, I was aware that there is some
chance that it would. Also, if you can find some solution for the
problem above, would be great.
Btw. my current 0.9.27 release plan is to do it as soon as I have
time, using basically the current state of code (with one last commit).
Is there something that you're currently working that would be a reason
wait some more time?
Ciao,
--- grischka
Ciao,
Michael.