🚀 go-pugleaf

I am posting this reply, received from Mitch Miers:

> Date: Fri, 16 Apr 93 11:31:58 CDT
> From: elmer!underdog!mitch@uu.psi.com (Mitch Miers)
> To: engdahl@aa.ab.com
> Subject: glibc-1.05.1
> 
> In article <1993Apr15.192709.1495@icd.ab.com>, you write:
> |> In article <EPT.93Apr14160116@brauer.harvard.edu> ept@math.harvard.edu (Eric
>  Twietmeyer) writes:
> |> >
> [stuff deleted]
> 
> I had the same problem, with gas2.0, gcc2.3.3.  I tried to post the question
> of the fix, but for some reason none of my posts ever hit the news groups.
> Anyway, in gas2.0, the file 'read.c', there is a check around line 436 to
> the function 'hash_find'.  This find fails for ".app"; however, the assembler
> source has the pseudo-op ".app-file".  The problem lies in the call to
> 'get_symbol_end()', around line 398 in 'read.c'.  This function, located in
> the file 'expr.c' around line 1122, uses the macro 'is_part_of_name()', which
> uses the table 'lex_type' in 'read.c' to see if a character is valid for
> an identifier.  THE '-' CHARACTER IS NOT MARKED AS VALID, NOR CAN IT BE.  The
> psuedo-op '.app-file' has a '-' in it, and thus gets truncated to '.app'.  The
> fix is not to include '-' as valid in the lex_type table, as that messes up
> operand parsing (where '-' is used as an operator).  The fix I found was to
> change '.app-file' to '.app_file' in 'read.c' and 'app.c'.  This pseudo-op is
> contained entirely within gas (it replaces #line... with .app-file ...), so
> there is no concern with changing gcc or gld.
> 
> Mitch
> 
> P.S., If you could post this, I'd appreciate it.
> 

-- 
Jonathan Engdahl, Sr. Project Engineer | engdahl@aa.ab.com N8XVY 313-998-2450
Allen-Bradley Co.                      | A Rockwell International Company
555 Briarwood Circle,                  | Industrial Communication Networks
Ann Arbor, Michigan, 48108, USA        | system design, software, ASICs