Re: appchk/libc functions

[Dave Prosser <dfp@sco.com>]

Stuart Anderson wrote:
> > It's one of the "new" sections added for IA-64.  The s stands for
> > "short".  There's also .sdata, .sdata1, and so on.  It's helpful for
> > this architecture as there is a substantial cut off in register+offset
> > addressing at around 22-24 bits, which is clearly much smaller than
> > the full 64 bit general addressing.
> 
> I figured it was something like that, but he is seeing it on an IA32 system.

That I cannot explain.

> > But, why does appchk care what names are used for ELF sections?
> 
> They are listed in the specs, so it checks. What does the linker/loader do
> with a section, if it doesn't recognize it?
> 
> > It's the attributes that are most important, since they are what's
> > used to determine how allocated sections are merged into segments.
> 
> I'm still waiting for the coffee to kick in, but do the attributes alone
> fully define the semantics of a section? IF I'm thinking of the right thing,
> the attributes aren't unique across sections, so it would somewhat ambiguous
> to depend on them alone.

The general rule for linking (as I understand it) is that all
sections with the same name, type and flags are concatenated in
the order they are seen by ld.  Then, all these bundles that have
the same flags and type that are allocatable will be put into a
common segment.

Here's what's in the gABI these days regarding merging of sections:

Rules for Linking Unrecognized Sections

If a link editor encounters sections whose headers contain OS-specific
values it does not recognize in the sh_type or sh_flags fields, the
link editor should combine those sections as described below. 

If the section's sh_flags bits include the attribute SHF_OS_NONCONFORMING,
then the section requires special knowledge to be correctly processed,
and the link editor should reject the object containing the section with
an error. 

Unrecognized sections that do not have the SHF_OS_NONCONFORMING attribute,
are combined in a two-phase process.  As the link editor combines sections
using this process, it must honor the alignment constraints of the input
sections (asserted by the sh_addralign field), padding between sections
with zero bytes, if necessary, and producing a combination with the maximum
alignment constraint of its component input sections. 

   1.In the first phase, input sections that match in name, type and
     attribute flags should be concatenated into single sections.
     The concatenation order should satisfy the requirements of any known
     input section attributes (e.g, SHF_MERGE and SHF_LINK_ORDER).  When
     not otherwise constrained, sections should be emitted in input order. 
   2.In the second phase, sections should be assigned to segments or other
     units based on their attribute flags. Sections of each particular
     unrecognized type should be assigned to the same unit unless
     prevented by incompatible flags, and within a unit, sections of the
     same unrecognized type should be placed together if possible. 

Non OS-specific processing (e.g. relocation) should be applied to
unrecognized section types.  An output section header table, if
present, should contain entries for unknown sections. Any unrecognized
section attribute flags should be removed.

(info)
It is recommended that link editors follow the same two-phase ordering
approach described above when linking sections of known types.  Padding
between such sections may have values different from zero, where appropriate. 

-- 
Dave Prosser dfp@sco.com (908)790-2358 Rm A332, SCO, Murray Hill, NJ