Darren J Moffat wrote:
> I see that libc_psr uses $(MAPFILE-FLTR) to bring in mapfile-filter.

First, some history:

This mapfile is used throughout the OSNet to build "standard"
filters:

     filter = LOAD ?RX;
     filter : ?A;

A "standard" filter need provide no backing implementation.  This
filter is simply a symbol table.  At runtime, ld.so.1 redirects any
bindings that would resolve to this filter to its associated filtee.

As there is no need for a backing implementation, no code within
the filter needs to be exercised.  Hence, we typically built the filter
for some empty C stub functions, or directly from mapfile symbol
definitions.   In either case, there is no need for a typical "text"
and "data" segmented file.  Hence, we use $(MAPFILE-FLTR) to create a
single segmented shared object, ie:

oxpoly 496.. elfdump -p /usr/lib/libdl.so.1

Program Header[0]:
     p_vaddr:      0               p_flags:    [ PF_X  PF_R ]
     p_paddr:      0               p_type:     [ PT_LOAD ]
     p_filesz:     0x6c3           p_memsz:    0x6c3
     p_offset:     0               p_align:    0x4

This single segment is much more efficient for ld.so.1 to load at
runtime, making filters built this way very cheap.


Now, it turns out that we've also used this same mapfile in places
where we've discovered small libraries, that contain no data, and
require no-relocations.  libc_psr is one case.  The file contains
a small amount of text, and because there's no need for a writable
data segment, we've created one text segment for the whole library.

We should really have renamed the mapfile to $(MAPFILE-ONETEXTSEG)
for this purpose.

Again, the rational is that the single text segment is much more
efficient to load, and for something like libc_psr (everyone uses
it), this can result in some savings.

So, we've used a "filter" mapfile to create a "filtee" in this
special case.

> I think I should be doing the same thing in my new libmd_psr filter.
> When I add $(MAPFILE-FLTR) I get relocation failures, what does
> this mean ?

You are providing implementation code that needs relocation.  This code,
if stuffed into the text segment, causes the errors you cite:

> Text relocation remains                         referenced
>     against symbol                  offset      in file
> bcopy                               0xc4        pics/md5.o
> MD5Update                           0x1a4       pics/md5.o

Bottom line, $(MAPFILE-FLTR) should only be used to create "standard"
filters, or single segmented libraries that contain no implemention
code or relocations.

-- 
Rod

Reply via email to