Re: [gold] PowerPC PLT

[Ian Lance Taylor <iant at google dot com>]

"David Edelsohn" <dje.gcc@gmail.com> writes:

> What is the relationship between different Output_data_space objects?

Think of each one as corresponding to an input section in an input
file.  In other words, there is no relationship between arbitrary
Output_data_space objects.  If you assign two Output_data_space
objects to the same output section, then they will be near each other
but need not be contiguous.

> Are Output_data_space objects contiguous?

They may be but there is no particular requirement that they be.  That
said, if you assign two different Output_data_space objects to the
same output section, and nothing else is assigned to that output
section, then they will be contiguous modulo alignment.

> I am trying to understand
> the meaning of offset() and address() for various Output_data_space
> objects attached to a single output section.

offset() is the file offset of the Output_data_space object in the
output file.  address() is the virtual address of the
Output_data_space object as seen by the executable when it runs.  When
writing the data to the output file, you need to look at offset().
When setting the value of symbols, you need to look at address().
Both numbers are only valid after layout is complete (e.g., during
relocation processing).  Both numbers are independent of the output
section.

> What is the relationship
> between set_data_size() for the output section and set_data_size() for
> the Output_data_space objects?

Your code needs to call set_data_size() for an Output_data_space
object, one way or another.  That is how the generic code determines
the size that it needs to allocate for your object.  For example, if
you create an Output_data_fixed_space section, you need to specify the
size at construction time.  For an Output_data_space object, you need
to call set_data_size, once, on that object when you know the final
size.  Or, for an Output_data_space object, you can instead call
set_current_data_size multiple times and not bother with calling
set_data_size; in that case the generic code will eventually set the
final size to the current size.

For an Output_section object, the generic layout code will handle
calling set_data_size.  The processor specific code should not need to
think about it.  This happens in Output_section::set_final_data_size,
called from Output_data::finalize_data_size, called from
Layout::set_section_offsets.  The data size of the output section will
be set to the sum of the sizes of the input sections and objects
attached to the output section, adjusting for alignment constraints.


> In other words, beyond the logical relationships, what are the semantics
> of how the various Output_data_space objects fit together and relate to one
> another within the Gold API?

The various Output_section_data objects (of which Output_data_space is
one) all correspond to input sections with linker-generated content.
The various things which create them all arrange to set their data
size and their alignment constraints.  When the processor backend
creates an Output_section_data object, it becomes responsible for
setting the size and alignment, and for attaching it to an output
section.  When those steps are taken, everything else happens in the
generic code.

Ian