libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Nick Alcock]

So I'm trying to get the deduplicating CTF linker in libctf ready for
release -- it's been a hard slog through a whole bunch of self-inflicted
design errors, but I'm almost there now, and the CTF section sizes are
looking good (e.g. all of objcopy, statically linked so including the
types for all the BFD machinery it uses, comes in at less than 70KiB of
.ctf, and I'm sure I can get it down further).

During early internal review, Jose Marchesi pointed out that some
long-preexisting Solaris-era code now found at
<https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=libctf/ctf-error.c;hb=HEAD>
is needlessly introducing dozens of relocs. Bruno wrote a nice little
automated fix for this general problem: it's included in Uli's DSO howto
at <https://www.akkadia.org/drepper/dsohowto.pdf>: rather than
re-engineering it, I thought I'd add a buncha comments and reuse the
code in libctf.

But it's probably long enough and surely tricksy enough to be
copyright-significant in the FSF's eyes, the DSO howto doesn't have any
sort of license stated, and its contents are most unlikely to be (C) FSF
in any case given Uli's stated opinions on the subject. That code
snippet is surely your work, so, Bruno: if anyone can give me permission
for reuse it in a GNU project, it would be you.

So, could you do so?

(Thanks!)

(If anyone else on the list has objections, please do say so.)

Re: libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Bruno Haible]

Hi Nick,

> Bruno wrote a nice little
> automated fix for this general problem: it's included in Uli's DSO howto
> at <https://www.akkadia.org/drepper/dsohowto.pdf>: rather than
> re-engineering it, I thought I'd add a buncha comments and reuse the
> code in libctf.
> 
> But it's probably long enough and surely tricksy enough to be
> copyright-significant in the FSF's eyes

The code I originally sent to Ulrich, and which I hereby put in the public
domain:

       #include <stddef.h>

       #define MSGSTRFIELD(line) MSGSTRFIELD1(line)
       #define MSGSTRFIELD1(line) str##line
       static struct msgstr_t {
       #define _S(s) char MSGSTRFIELD(__LINE__) [sizeof(s)];
       #include "stringtab.h"
       #undef _S
       } msgstr = {
       #define _S(s) s,
       #include "stringtab.h"
       #undef _S
       };
       static int msgidx[] = {
       #define _S(s) offsetof(struct msgstr_t, MSGSTRFIELD(__LINE__)),
       #include "stringtab.h"
       #undef _S
       };

       const char *errstr (int nr) {
         return (char*)&msgstr + msgidx[nr];
       }

       And stringtab.h contains:

         _S("message for err1")
         _S("message for err2")
         _S("message for err3")

The changes Ulrich did were:
  - Add a parameter 'n' to the _S macro, to avoid mismatches between index
    and message.
  - Turn msgstr_t into a union with an unnamed struct as first element,
    to get rid of the cast (char*)&msgstr that may trigger a GCC warning.

Bruno

Re: libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Nick Alcock]

On 14 Apr 2020, Bruno Haible spake thusly:

>> Bruno wrote a nice little
>> automated fix for this general problem: it's included in Uli's DSO howto
>> at <https://www.akkadia.org/drepper/dsohowto.pdf>: rather than
>> re-engineering it, I thought I'd add a buncha comments and reuse the
>> code in libctf.
>> 
>> But it's probably long enough and surely tricksy enough to be
>> copyright-significant in the FSF's eyes
>
> The code I originally sent to Ulrich, and which I hereby put in the public
> domain:

Thank you! Suitably-modified versions of this land in libctf soon (and
if other bits of binutils want to use it, we can migrate it into
libibierty later).

Re: libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Bruno Haible]

Nick Alcock wrote:
> Thank you! Suitably-modified versions of this land in libctf soon (and
> if other bits of binutils want to use it, we can migrate it into
> libibierty later).

As an application programmer, I don't really want to spend time minimizing
the number of relocations of a library or (now that -fPIE is in wide use)
of an executable. I wish GCC would offer attributes that make this task
easier.

Bruno

Re: libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Andreas Schwab]

On Apr 14 2020, Bruno Haible wrote:

> As an application programmer, I don't really want to spend time minimizing
> the number of relocations of a library or (now that -fPIE is in wide use)
> of an executable. I wish GCC would offer attributes that make this task
> easier.

See -fsection-anchors.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: reducing number of relocations

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Andreas Schwab wrote:
> > As an application programmer, I don't really want to spend time minimizing
> > the number of relocations of a library or (now that -fPIE is in wide use)
> > of an executable. I wish GCC would offer attributes that make this task
> > easier.
> 
> See -fsection-anchors.

Thanks. Unfortunately this option has no effect for some CPUs [1], and in
particular not for x86_64.

Among the major targets, it seems to be only supported for alpha, arm, arm64,
mips, powerpc, riscv.

And on a platform where it is supported, it has no effect in the given case:

$ mips64-linux-gnuabi64-gcc-5 -O2 -c -Wall foo.c -fsection-anchors
$ mips64-linux-gnuabi64-readelf -r foo.o

shows as many relocations as

$ mips64-linux-gnuabi64-gcc-5 -O2 -c -Wall foo.c
$ mips64-linux-gnuabi64-readelf -r foo.o

Bruno

[1] https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Optimize-Options.html

[-- Attachment #2: foo.c --]
[-- Type: text/x-csrc, Size: 3741 bytes --]

#include <stddef.h>

static const char *const _ctf_errlist[] = {
  "File is not in CTF or ELF format",		     /* ECTF_FMT */
  "BFD error",					     /* ECTF_BFDERR */
  "File uses more recent CTF version than libctf",   /* ECTF_CTFVERS */
  "Ambiguous BFD target",			     /* ECTF_BFD_AMBIGUOUS */
  "Symbol table uses invalid entry size",	     /* ECTF_SYMTAB */
  "Symbol table data buffer is not valid",	     /* ECTF_SYMBAD */
  "String table data buffer is not valid",	     /* ECTF_STRBAD */
  "File data structure corruption detected",	     /* ECTF_CORRUPT */
  "File does not contain CTF data",		     /* ECTF_NOCTFDATA */
  "Buffer does not contain CTF data",		     /* ECTF_NOCTFBUF */
  "Symbol table information is not available",	     /* ECTF_NOSYMTAB */
  "Type information is in parent and unavailable",   /* ECTF_NOPARENT */
  "Cannot import types with different data model",   /* ECTF_DMODEL */
  "File added to link too late",		     /* ECTF_LINKADDEDLATE */
  "Failed to allocate (de)compression buffer",	     /* ECTF_ZALLOC */
  "Failed to decompress CTF data",		     /* ECTF_DECOMPRESS */
  "External string table is not available",	     /* ECTF_STRTAB */
  "String name offset is corrupt",		     /* ECTF_BADNAME */
  "Invalid type identifier",			     /* ECTF_BADID */
  "Type is not a struct or union",		     /* ECTF_NOTSOU */
  "Type is not an enum",			     /* ECTF_NOTENUM */
  "Type is not a struct, union, or enum",	     /* ECTF_NOTSUE */
  "Type is not an integer, float, or enum",	     /* ECTF_NOTINTFP */
  "Type is not an array",			     /* ECTF_NOTARRAY */
  "Type does not reference another type",	     /* ECTF_NOTREF */
  "Input buffer is too small for type name",	     /* ECTF_NAMELEN */
  "No type information available for that name",     /* ECTF_NOTYPE */
  "Syntax error in type name",			     /* ECTF_SYNTAX */
  "Symbol table entry or type is not a function",    /* ECTF_NOTFUNC */
  "No function information available for symbol",    /* ECTF_NOFUNCDAT */
  "Symbol table entry is not a data object",	     /* ECTF_NOTDATA */
  "No type information available for symbol",	     /* ECTF_NOTYPEDAT */
  "No label information available for that name",    /* ECTF_NOLABEL */
  "File does not contain any labels",		     /* ECTF_NOLABELDATA */
  "Feature not supported",			     /* ECTF_NOTSUP */
  "Invalid enum element name",			     /* ECTF_NOENUMNAM */
  "Invalid member name",			     /* ECTF_NOMEMBNAM */
  "CTF container is read-only",			     /* ECTF_RDONLY */
  "Limit on number of dynamic type members reached", /* ECTF_DTFULL */
  "Limit on number of dynamic types reached",	     /* ECTF_FULL */
  "Duplicate member or variable name",		     /* ECTF_DUPLICATE */
  "Conflicting type is already defined",	     /* ECTF_CONFLICT */
  "Attempt to roll back past a ctf_update",	     /* ECTF_OVERROLLBACK */
  "Failed to compress CTF data",		     /* ECTF_COMPRESS */
  "Failed to create CTF archive",		     /* ECTF_ARCREATE */
  "Name not found in CTF archive",		     /* ECTF_ARNNAME */
  "Overflow of type bitness or offset in slice",     /* ECTF_SLICEOVERFLOW */
  "Unknown section number in dump",		     /* ECTF_DUMPSECTUNKNOWN */
  "Section changed in middle of dump",		     /* ECTF_DUMPSECTCHANGED */
  "Feature not yet implemented",		     /* ECTF_NOTYET */
  "Internal error in link",			     /* ECTF_INTERNAL */
  "Type not representable in CTF"		     /* ECTF_NONREPRESENTABLE */
};

static const int _ctf_nerr = sizeof (_ctf_errlist) / sizeof (_ctf_errlist[0]);

#define ECTF_BASE 0

const char *
ctf_errmsg (int error)
{
  const char *str;

  if (error >= ECTF_BASE && (error - ECTF_BASE) < _ctf_nerr)
    str = _ctf_errlist[error - ECTF_BASE];
  else
    str = NULL;

  return (str ? str : "Unknown error");
}

Re: reducing number of relocations

[Andreas Schwab]

On Apr 15 2020, Bruno Haible wrote:

> $ mips64-linux-gnuabi64-gcc-5 -O2 -c -Wall foo.c -fsection-anchors
> $ mips64-linux-gnuabi64-readelf -r foo.o
>
> shows as many relocations as
>
> $ mips64-linux-gnuabi64-gcc-5 -O2 -c -Wall foo.c
> $ mips64-linux-gnuabi64-readelf -r foo.o

You need to compare fully linked objects.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: libctf: can I reuse Bruno's code from appendix B of Uli's DSO howto?

[Nick Alcock]

On 14 Apr 2020, Bruno Haible verbalised:

> Nick Alcock wrote:
>> Thank you! Suitably-modified versions of this land in libctf soon (and
>> if other bits of binutils want to use it, we can migrate it into
>> libibierty later).
>
> As an application programmer, I don't really want to spend time minimizing
> the number of relocations of a library or (now that -fPIE is in wide use)
> of an executable. I wish GCC would offer attributes that make this task
> easier.

Neither do I -- but this also let me autogenerate the error list from
the ctf-api.h header file, which was my real goal in this: the luxury of
needing to change only one place when adding an error. :)

-- 
NULL && (void)