Re: Problem with keyword parsing for gas

Re: Problem with keyword parsing for gas

[Nick Kelsey]

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

After sleeping on this I have come to the conclusing that an underscore
should always be considered a symbol character regardless how weird the port
is so I have submitted the attached patch to binutils for review.

Nick

----- Original Message -----
From: "Nick Kelsey" <nickk@ubicom.com>
To: <jafa@silicondust.com>
Sent: Tuesday, December 17, 2002 6:03 PM
Subject: Problem with keyword parsing for gas


*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi guys,

A change was made to cgen in mid 2001 that affects keyword parsing....

opcodes/cgen-asm.c (early 2001): cgen_parse_keyword:

  /* Now allow letters, digits, and _.  */
  while (((p - start) < (int) sizeof (buf))
  && (isalnum ((unsigned char) *p) || *p == '_'))
    ++p;

This would correctly treat <keyword>_temp as a non keyword.

The new code reads as follows:

  /* Allow letters, digits, and any special characters.  */
  while (((p - start) < (int) sizeof (buf))
  && *p
  && (ISALNUM (*p) || strchr (keyword_table->nonalpha_chars, *p)))
    ++p;

This does not treat an underscore as a symbol character and gas barfs on a
symbol that starts <keyword>underscore.

Possible solutions that spring to mind... Add an explicit check for
underscore to the while statement, or add an underscore to nonalpha_chars.

Adding an underscore to nonalpha_chars is easy as it is global and
pre-initialized...

CGEN_KEYWORD xxx_cgen_opval_register_names =
{
  & xxx_cgen_opval_register_names_entries[0],
  121,
  0, 0, 0, 0, "_"
};

However this is generated code so there are bigger implications.

I am completly open to suggestions and implications as to the best way to
fix this without breaking other ports.

Thanks

Nick





[-- Attachment #2: gas_cgen_parse.patch --]
[-- Type: application/octet-stream, Size: 709 bytes --]

*** cgen-asm.c	26 Nov 2002 18:12:48 -0000
--- cgen-asm.c	18 Dec 2002 02:16:00 -0000
*************** cgen_parse_keyword (cd, strp, keyword_ta
*** 225,231 ****
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (ISALNUM (*p) || strchr (keyword_table->nonalpha_chars, *p)))
      ++p;
  
    if (p - start >= (int) sizeof (buf))
--- 225,233 ----
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (ISALNUM (*p) ||
! 	     strchr (keyword_table->nonalpha_chars, *p) ||
! 	     *p == '_'))
      ++p;
  
    if (p - start >= (int) sizeof (buf))

[-- Attachment #3: ChangeLog --]
[-- Type: application/octet-stream, Size: 192 bytes --]

2002-12-18  Nick Kelsey  <nickk@ubicom.com>

	* cgen-asm.c (cgen_parse_keyword): Added underscore to symbol character
	check to fix false keyword trigger with names such as <keyword>_foo.

Problem with keyword parsing for gas

[Nick Kelsey]

Hi guys,

A change was made to cgen in mid 2001 that affects keyword parsing....

opcodes/cgen-asm.c (early 2001): cgen_parse_keyword:

  /* Now allow letters, digits, and _.  */
  while (((p - start) < (int) sizeof (buf))
  && (isalnum ((unsigned char) *p) || *p == '_'))
    ++p;

This would correctly treat <keyword>_temp as a non keyword.

The new code reads as follows:

  /* Allow letters, digits, and any special characters.  */
  while (((p - start) < (int) sizeof (buf))
  && *p
  && (ISALNUM (*p) || strchr (keyword_table->nonalpha_chars, *p)))
    ++p;

This does not treat an underscore as a symbol character and gas barfs on a
symbol that starts <keyword>underscore.

Possible solutions that spring to mind... Add an explicit check for
underscore to the while statement, or add an underscore to nonalpha_chars.

Adding an underscore to nonalpha_chars is easy as it is global and
pre-initialized...

CGEN_KEYWORD xxx_cgen_opval_register_names =
{
  & xxx_cgen_opval_register_names_entries[0],
  121,
  0, 0, 0, 0, "_"
};

However this is generated code so there are bigger implications.

I am completly open to suggestions and implications as to the best way to
fix this without breaking other ports.

Thanks

Nick