sid cgen cpus broken by absence of pic libiberty

sid cgen cpus broken by absence of pic libiberty

[Jim Blandy]

I think the SID build is broken for CGEN-based processors.

The libcgencpu.la library, built in sid/component/cgen-cpu, depends on
libiberty.  There are some occasional uses of xmalloc in tracedis.cxx,
but libcgencpu.la also uses files from libopcodes, which use the
"safe-ctype.h" character classification functions.  Fine.

Unfortunately, libiberty no longer builds PIC versions of its .o
files.  It used to, but there was long and highly confusing discussion
about how to fix things in December, which resulted in many large
patches, all of which were eventually reverted.  See the binutils
mailing list.  I can't find the discussion of why H.J. Lu reverted the
hard work he'd done getting libiberty to use libtool, but it sure
looked like a testing nightmare (AIX and an HP-UX x IA64 build were
both brought up as problematic cases).

And if there are no PIC libiberty objects, then libcgencpu.la
certainly can't use libiberty.

Since worthies much worthier than I have struggled with making
libiberty produce PIC object files and failed, I'm inclined to work on
making the opcodes stuff and sid no longer depend on libiberty.  It's
going to involve cringe-inducing patch hunks like this:

*************** cgen_parse_keyword (CGEN_CPU_DESC cd ATT
*** 216,222 ****
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (ISALNUM (*p)
  	     || *p == '_'
  	     || strchr (keyword_table->nonalpha_chars, *p)))
      ++p;
--- 216,224 ----
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (('a' <= *p && *p <= 'z')
!              || ('A' <= *p && *p <= 'Z')
!              || ('0' <= *p && *p <= '9')
  	     || *p == '_'
  	     || strchr (keyword_table->nonalpha_chars, *p)))
      ++p;

Does that sound reasonable (well, reasonable with a clothespin on the
nose) to folks?

sid cgen cpus broken by absence of pic libiberty

[Doug Evans]

Jim Blandy writes:
 > *************** cgen_parse_keyword (CGEN_CPU_DESC cd ATT
 > *** 216,222 ****
 >     /* Allow letters, digits, and any special characters.  */
 >     while (((p - start) < (int) sizeof (buf))
 >   	 && *p
 > ! 	 && (ISALNUM (*p)
 >   	     || *p == '_'
 >   	     || strchr (keyword_table->nonalpha_chars, *p)))
 >       ++p;
 > --- 216,224 ----
 >     /* Allow letters, digits, and any special characters.  */
 >     while (((p - start) < (int) sizeof (buf))
 >   	 && *p
 > ! 	 && (('a' <= *p && *p <= 'z')
 > !              || ('A' <= *p && *p <= 'Z')
 > !              || ('0' <= *p && *p <= '9')
 >   	     || *p == '_'
 >   	     || strchr (keyword_table->nonalpha_chars, *p)))
 >       ++p;
 > 
 > Does that sound reasonable (well, reasonable with a clothespin on the
 > nose) to folks?

Well, I'd still tuck the code away in macro or whatever.
Or, use just plain ctype.  This is just one example so
who knows what libiberty actually brings to the party
in all the affected cases though.

Seems pretty sad though, eh?

Maybe the thing to do is create one's own mini-libiberty
that one controls and so isn't sacked with the politics or
whatever of binutils.  Keeping the naming close to libiberty
would allow an easier transition back to libiberty if such
a day arrives.

Re: sid cgen cpus broken by absence of pic libiberty

[Frank Ch. Eigler]

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

Hi -


> I think the SID build is broken for CGEN-based processors.
> [...]
> Since worthies much worthier than I have struggled with making
> libiberty produce PIC object files and failed, I'm inclined to work on
> making the opcodes stuff and sid no longer depend on libiberty.  [...]

Thanks.  I'd like to "ditto" dje and suggest in this case going to
direct ctype.h.  Let's lose library/macro indirection unless it is
known to help.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]