On Feb 24, 9:05 pm, "Jim Dehnert" <
dehn...@gmail.com> wrote:
> On Sun, Feb 24, 2008 at 2:05 PM, H.J. <
hjl.to...@gmail.com> wrote:
>
> > Should weak hidden undefined symbol be allowed? The problem is when
> > compiler sees a hidden symbol, it assumes
> > that it will be defined in the same component and optimizes its
> > access. If the hidden symbol is weak and undefined,
> > our linker won't report the error since the undefined symbol weak is
> > allowed. Although its value is 0, it may be
> > impossible to make its address to 0 in a shared library since the load
> > address of a shared library isn't known at
> > link-time.
>
> Why does that matter? That's an absolute zero, not a relative zero.
>
For
foo ? foo() : puts( "foo == null, skipped." );
if foo is hidden, compiler assumes it will be defined in the same
component. On
x86-64, compiler may generate the following PIC code
leaq foo(%rip), %rax
testq %rax, %rax
PC relative address is used here. It will work correctly if foo is
defined in
the same component. If foo is weak, undefined and hidden. foo will be
zero. For normal executable, since the load address is fixed, llinker
can
turn
leaq foo(%rip), %rax
into
leaq -PC(%rip), %rax
rax will be 0. But for shared library, linker doesn't know the load
address.
To load 0 into %rax, linker will generate relocation in .text section
and
dynamic linker has to modify LEA at run-time to load 0 into rax.
Generate a DSO with DT_TEXTREL isn't very desirable. We want
to avoid it if possible. It is odd to tell compiler that you can't
always
assume a hidden symbol will be defined in the same component
when you access it.
H.J.
H.J.