Re: [gold] PowerPC PLT

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

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

> On Thu, Nov 20, 2008 at 3:04 PM, Ian Lance Taylor <iant@google.com> wrote:
>
>>> 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 do not mean contiguous with respect to one another, I am asking
> about data written to an Output_data_space object.  Can I think of
> Output_data_space objects as contiguous chunks of linker-created
> data within an output section?

Ah.  Yes.  Each individual Output_data_space object represents a
contiguous set of bytes in the output file.  Each individual
Output_data_space object corresponds to an individual input section in
an input file.


>>> 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.
>
> My question was meant to focus on the relationship between offset
> for various Output_data_space objects within an output section.
> Similarly for address.
>
> PPC32 new ABI PLT contains three sub-sections: function addresses
> that are considered the PLT itself, stubs, and glink code.  As with
> other implementations of do_write(), I use offset() and data_size()
> to call get_output_view() for the views of the output buffers.  And,
> at the end of writing, I ensure that the difference in pointers match
> the size.
>
> Currently I write the three sub-sections concurrently, assuming that
> my three output views each point into separate, contiguous chunks
> of the PLT output section.
>
> set_data_size() on the Output_data_space objects sets the size
> of those chunks, but set_data_size() on the PLT class presumably
> sets the size of the entire output section.  I'm trying to figure out what
> I need to do to allocate space for the first part of the PLT and offset
> the stub and glink sub-sections.  Will Gold offset the sub-sections
> implicitly?  Should I create another Output_data_space sub-section
> within PLT for the function addresses and not access the PLT class
> view directly, not set the PLT class size directly?
>
> My questions are not about what the APIs mean, but how they fit
> together and interact for multiple Output_data_space objects within
> a subclass of Output_section_data -- Output_data_plt_powerpc.

It sounds like you have a PLT class which is a child class of
Output_data_section, and that that class itself wants to be built up
out of classes which are themselves child classes of
Output_data_section.  I suppose you can do it that way but it's not
designed to work that way.  The usual approach is that each
Output_section has a list of Output_section_data objects (and input
sections), but that those Output_section_data objects do not
themselves contain other Output_section_data objects.

All of these classes are child classes of Output_data, but there is a
distinction that matters: an Output_section contains
Output_section_data objects (and input sections).  Output_section_data
objects do not contain anything.

I would advice one of two approaches:

1) Make the PLT class be a subclass of Output_section_data.  Let it
build up the information that it needs in class-private data
structures.  Have the do_write method walk through those class-private
data structures to produce the whole PLT at once.  Do not produce any
other Output_section_data objects for the PLT.

2) Create a separate Output_section_data object for each part of the
PLT.  Manage them separately.  You can have one of them be the main
entry point for PLT manipulation if appropriate.

If the three parts of the PLT should not be contiguous in the output
file--e.g., if they should go into different output sections--then you
must use alternative 2.  Otherwise either alternative should work.

Ian