Displacement Relocations

Error conditions might occur if displacement relocations are applied to a data item, which itself can be used in a copy relocation. The details of copy relocations are covered in "Copy Relocations".

A displacement relocation remains valid when both the relocated offset and the target to which it is relocated remain separated by the same displacement. A copy relocation is one where a global data item within a shared object is copied to the .bss of an executable, to preserve the executable's read-only text segment. If the copied data has a displacement relocation applied to it, or an external relocation is a displacement into the copied data, the displacement relocation becomes invalidated.

The areas to address in trying to catch these sorts of errors are:

• When generating a shared object, flag any potential copy relocatable data items that can be problematic if they are involved in a displacement relocation.

• When generating an executable, flag the creation of a copy relocation whose data is involved in a displacement relocation.

The problem with the former item is that many shared objects already exist that use displacement relocations against global data, and this data can potentially be copy relocated. During construction of a shared object, the link-editor has no knowledge of what references might be made to it; thus all that can be flagged are potential problems.

The problem with the latter item is that displacement relocations applied to a shared object might be completed during its creation at link-edit time. Therefore a link-edit of an application that references this shared object has no knowledge of a displacement being in effect in any copy-relocated data.

To help diagnose these problem areas, the link-editor indicates the displacement relocation use of a dynamic object with one or more dynamic DT_FLAGS_1 flags (see Table 7-45). In addition, the link-editors' -zverbose option can be used to display suspicious relocations.

For example, if you create a shared object with a global data item, bar[], which has a displacement relocation applied to it, then this item could be copy-relocated if referenced from a dynamic executable. The link-editor warns of this condition with:

$ cc -G -o libfoo.so.1 -z verbose -Kpic foo.o
ld: warning: relocation warning: R_SPARC_DISP32: file foo.o: symbol foo: \
    displacement relocation to be applied to the symbol bar: at 0x194: \
    displacement relocation will be visible in output image

If you now create an application that references the data item bar[], a copy relocation will be created which results in the displacement relocation being invalidated. Because the link-editor can explicitly discover this situation, an error message is generated regardless of using the -zverbose option:

$ cc -o prog prog.o -L. -lfoo
ld: warning: relocation error: R_SPARC_DISP32: file foo.so: symbol foo: \
    displacement relocation applied to the symbol bar at: 0x194: \
    the symbol bar is a copy relocated symbol

These error conditions can be avoided by insuring that the symbol definition being relocated (offset) and the symbol target of the relocation are both local. This can be achieved using "static" definitions or the link-editor's scoping technology (see "Reducing Symbol Scope"). Access to data within shared objects is best provided by functional interfaces.

ldd(1), when used with either the -d or -r options, uses the displacement dynamic flags to generate similar relocation warnings.