Re: Move ldsodefs.h audit definitions to sysdeps directories

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Wed, Jul 18, 2012 at 8:36 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> Continuing the process of moving system-specific configuration to
> sysdeps directories (making libc targets more like ports ones), this
> patch moves the architecture-specific pltenter and pltexit members of
> struct audit_ifaces in sysdeps/generic/ldsodefs.h to
> architecture-specific ldsodefs.h files, in the same way already used
> for ports architectures.
>
> Tested x86 and x86_64.  Could architecture maintainers test/review for
> the other architectures?
>
> Note that while I think it's appropriate to do the incremental cleanup
> this way - move the definitions out using the facilities that already
> exist for ports architectures - I don't think this is the ideal shape
> for this configuration information.  There is similar, overlapping and
> duplicative, information in bits/link.h, dl-machine.h, ldsodefs.h,
> tst-audit.h and sotruss-lib.c, and once the libc architectures have
> been made to use tst-audit.h in the same way as ports architectures, I
> think some further cleanup will be appropriate.
>
> The whole idea of using a union here in struct audit_ifaces seems
> unnecessary; each glibc build will use exactly one pltenter interface
> and exactly one pltexit interface.  So architectures should just need
> to say what the _regs and _retval types involved in those interfaces
> are (no need define architecture-specific names for the structure
> fields) and then the declarations could go in generic code.  Although
> the involvement of bits/link.h - an installed header - may mean
> duplication of information can't be completely eliminated, it would
> seem reasonable to unify all the information outside bits/link.h into
> a single noninstalled header used in both the implementation and the
> audit testcases.

Some of the oddness seems to come about for hysterical raisins in that
the Solaris interface was designed like this and the glibc interface
was a direct copy[1].

> 2012-07-18  Joseph Myers  <joseph@codesourcery.com>
>
>         * sysdeps/generic/ldsodefs.h (struct La_i86_regs): Remove.
>         (struct La_i86_retval): Likewise.
>         (struct La_x86_64_regs): Likewise.
>         (struct La_x86_64_retval): Likewise.
>         (struct La_x32_regs): Likewise.
>         (struct La_x32_retval): Likewise.
>         (struct La_ppc32_regs): Likewise.
>         (struct La_ppc32_retval): Likewise.
>         (struct La_ppc64_regs): Likewise.
>         (struct La_ppc64_retval): Likewise.
>         (struct La_sh_regs): Likewise.
>         (struct La_sh_retval): Likewise.
>         (struct La_s390_32_regs): Likewise.
>         (struct La_s390_32_retval): Likewise.
>         (struct La_s390_64_regs): Likewise.
>         (struct La_s390_64_retval): Likewise.
>         (struct La_sparc32_regs): Likewise.
>         (struct La_sparc32_retval): Likewise.
>         (struct La_sparc64_regs): Likewise.
>         (struct La_sparc64_retval): Likewise.
>         (struct audit_ifaces): Remove architecture-specific pltenter and
>         pltexit members.
>         * sysdeps/i386/ldsodefs.h: New file.
>         * sysdeps/powerpc/ldsodefs.h: Likewise.
>         * sysdeps/s390/ldsodefs.h: Likewise.
>         * sysdeps/sh/ldsodefs.h: Likewise.
>         * sysdeps/sparc/ldsodefs.h: Likewise.
>         * sysdeps/x86_64/ldsodefs.h: Likewise.

Thanks for the cleanup, in general this looks good to me.

I had one question...

> diff --git a/sysdeps/i386/ldsodefs.h b/sysdeps/i386/ldsodefs.h
> new file mode 100644
> index 0000000..74880e9
> --- /dev/null
> +++ b/sysdeps/i386/ldsodefs.h
> @@ -0,0 +1,40 @@
> +/* Run-time dynamic linker data structures for loaded ELF shared objects.
> +   Copyright (C) 1995-2012 Free Software Foundation, Inc.

... why are new files getting a 1995-2012 copyright?

Is it because the contents of the file originated from a file that held
copyright for those years?

Cheers,
Carlos.

[1] http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-1242.html