Re: [PING^2][PATCH] in_plt_section: support alternate stub section names

[Pedro Alves <palves at redhat dot com>]

On 06/24/2013 11:58 PM, Maciej W. Rozycki wrote:
> On Mon, 24 Jun 2013, Pedro Alves wrote:
>> I think it'd be better to reinstate IN_SOLIB_TRAMPOLINE, modernized
>> as a gdbarch hook.  The default gdbarch_in_solib_trampoline
>> would then be in_plt_section.  But MIPS would install its
>> own version, based on the existing mips_linux_in_dynsym_resolve_code,
>> with your changes:
>>
>> static int
>> mips_linux_in_solib_trampoline (CORE_ADDR pc)
>> {
>>   /* Check whether the PC is in the .plt section, used by non-PIC
>>      executables.  */
>>   if (in_plt_section (pc))
>>      return 1;
>>
>>   /* Likewise for the stubs.  They live in the .MIPS.stubs section these
>>      days, so we check if the PC is within, than fall back to a pattern
>>      match.  */
>>   if (mips_linux_in_dynsym_stub (pc))
>>      return 1;
> 
>  You obviously mean in_mips_stubs_section here, don't you?

Yep.

>> As bonus, we'd no longer need the mips_svr4_so_ops ugly
>> hack in mips-linux-tdep.c at all:

...

>  Indeed, mips_linux_in_dynsym_resolve_code will then go in its current 
> form, becoming gdbarch's in_solib_trampoline backend.  It sounds like a 
> plan to me, thanks for the hint, I'll give it a shot.

Great, thanks.

>>>> static inline is fine with me.  However, what I really dislike is the
>>>> inclusion of solib-svr4.h in parts of the debugger that have nothing
>>>> to do with SVR4, or even are implementing a different shared library
>>>> support backend, like solib-frv.c solib-dsbt.c, solib-target.c, etc.
>>>> That's really an abstraction violation, there bits have nothing to so
>>>> with SVR4.
>>>
>>>  Umm, perhaps we have a file naming confusion in our sources 
>>
>> GDB supports various different shared library mechanisms.
>> Each is abstracted out behind a "struct target_so_ops" instance,
>> and implemented on a solib-*.c file:
>>
>> $ ls solib-*.c
>> solib-aix.c     solib-dsbt.c  solib-ia64-hpux.c  solib-osf.c   solib-som.c
>> solib-sunos.c  solib-target.c  solib-darwin.c  solib-frv.c   solib-irix.c
>> solib-pa64.c  solib-spu.c  solib-svr4.c
>>
>> Some of these modules need to export functions to other modules, and
>> therefore have a corresponding .h file.
>>
>> Not sure what isn't clear in the naming.
> 
>  Well, it may be my view of things -- I see SVR4 (as far as binary file 
> formats are concerned; there's certainly a lot beyond that in SVR4) as the 
> set of features as defined back in mid 1990s, starting from the ELF format 
> itself and including the way ELF shared libraries are handled in 
> particular.  So for me solib-svr4.c would then be the base feature set 
> common to all ELF shared library systems, and then any features beyond 
> that, added as newer systems invented them, included in their respective 
> add-on modules.

Many ELF systems supported will use solib-svr4.c.
However, each solib-foo.c module implements it's own struct target_so_ops.
They're all decoupled and independent from each other.  If a system is
sufficiently svr4-like, it'll use solib-svr4.c.  But e.g., solib-target.c is used
for the Windows port, which is COFF/PE as you know.  Or e.g., the sh/fr-v/bfin/tic6x
ports which are ELF based, but use FDPIC or DSBT (solib-frv.c, solib-dsbt.c),
and these ports don't include solib-srv4.c in the build at all, even though
the FDPIC/DSBT models are clearly inspired by SVR4 (and mention so in their
ABIs documents even).  Comparing solib-dsbt.c/solib-frv.c with solib-srv4.c,
and to me it looks like the similarities are only superficial.  A diff between
solib-svr4.c and solib-frv.c finds more difference than similarity.

The included-in-build issue is actually a good mental test --- say in_plt_section
was indeed implemented as a static inline in solib-svr4.h, instead of objfiles.h.
At some point, we decide it's too big to be inline, and make it extern.
Where would we define it then?  We wouldn't be able to put the definition
in solib-svr4.c, because of e.g., the Windows ports that don't include
solib-svr4.o in the build, even though your previous proposal made
solib-target.c include solib-svr4.h.

> 
>  E.g. if an ELF shared library system FrobOS running on an odd processor 
> added a capability to map segments of a library to memory in the reverse 
> direction, but supported all the other usual library features, then it 
> would use solib-svr4.c for the usual services and additionally solib-rev.c 
> for the reverse-mapping features.  But as I say, perhaps it's my view of 
> things that is reversed. ;)

If it's a minor detail, sure.  The MIPS case with its overriding of
in_dynsym_resolve_code is an example.  NTO/QNX is another example --
i386-nto-tdep.c:i386nto_init_abi.

>  Hmm, I never really dug into this area, but from your description I 
> gather that the line between the individual ELF solib-*.c modules is not 
> as clear as it probably should be.  I.e. I don't know exactly what the 
> relationship between SunOS and a generic SVR4 system wrt shared libraries 
> is, but assuming SVR4 is a strict superset of SunOS, then I'd expect 
> solib-svr4.c to implement the SVR4 additions only and rely on 
> solib-sunos.c for the rest.  All the SVR4 systems and ones that are a 
> superset of SVR4 features would useboth solib-svr4.c and solib-sunos.c, 
> and obviously SunOS would only use solib-sunos.c.

Nope.  solib-sunos.c is about a.out SunOS, though it's
actually only used by *BSD a.out ports, nowadays.

/* The shared library implementation found on BSD a.out systems is
   very similar to the SunOS implementation.  However, the data
   structures defined in <link.h> are named very differently.  Make up
   for those differences here.  */

We no longer support !ELF SunOS.  The Solaris support uses solib-svr4.c.

solib-sunos.c is self contained, as are all solib-*.c modules.
The differences to svr4 add up enough that bundling support in the
same module would be harder to maintain, IMO, and obviously in the
opinion of whoever split them up (Kevin, 2001, git 968327f).

> 
>  Contrariwise if a generic SVR4 system was actually not a superset of 
> SunOS and the latter had some extra features beyond a common ELF shared 
> library feature set, then a base ELF shared library module, say 
> solib-elf.c would handle the common feature set.  Than solib-sunos.c would 
> handle the SunOS additions and consequently SunOS would use solib-elf.c 
> and solib-sunos.c.  Similarly a generic SVR4 system would use solib-elf.c 
> and solib-svr4.c.  And that dreaded FrobOS would use all of solib-elf.c, 
> solib-svr4.c and solib-rev.c.

The question is then how much is there really to be shared.
I can't think of much.  Yeah, maybe in_plt_section could go there.
As I mention, even Symbian has plts (the system doesn't run elf
binaries, though the toolchain is elf based, with the binaries
post-linker processed into the final e32 format for space constrains
issues, though clearly there's elf inspiration.).  But if you
look at it as just a wrapper for pc_in_section that helps avoid
typing ".plt" in the source, there's no need to put any semantic
awareness of PLTs in the section's contents in the function itself;
leave that to the callers.  With the introduction of
gdbarch_in_solib_trampoline, uses of in_plt_section will go down
further, so I'm not sure I'd bother, though I certainly wouldn't object.

>> Please mention the inclusion of "objfiles.h" in the ChangeLog,
>> in the files that needed it.  Okay with that change, but I'd
>> like the idea above to be explored.
> 
>  OK, thanks.  Here's the final ChangeLog entry I've committed.  I'll look 
> into redesigning the pieces you've mentioned above, but I'll ask for 
> assistance with testing as I have no access to non-Linux MIPS ELF shared 
> library systems.

Thanks!

-- 
Pedro Alves