RE: gas/ia64 "data in a code section" problem

RE: gas/ia64 "data in a code section" problem

[Jim Wilson]

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

On Tue, 2004-06-29 at 22:40, Belochapka, Konstantin wrote:
> Of course I agree that if anyone puts a data into code segment does this at his own risk. But my point is that an assembler also should not any restriction based on assumption of any potential problem. 
> The situation when IA64 assembler starts next bundle from an address that is not aligned on 16 bytes
> in my opinion is a bug that need to be corrected or it might be mentioned in a README file that after a data .align 16 directive is a requirement. But emitting error message would be not good solution, warning might be more appropriate.

A similar problem was reported against the PowerPC assembler a few days
ago.  See binutils bug 248.
    http://sources.redhat.com/bugzilla/show_bug.cgi?id=248
A patch was added that generates an error for misaligned PPC
instructions.
    http://sources.redhat.com/ml/binutils/2004-07/msg00017.html

I added a patch so we get the same error for misaligned IA-64
instructions.  It is attached.  You will need the above referenced patch
for this one to work.  This should make it easier to identify places
where you need to emit an alignment directive.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

[-- Attachment #2: patch.addr.error --]
[-- Type: text/plain, Size: 2261 bytes --]

2004-07-03  James E Wilson  <wilson@specifixinc.com>

	* config/tc-ia64.c (emit_one_bundle): Check and set insn_addr.
	* config/tc-ia64.h (md_frag_check): Define.

Index: tc-ia64.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-ia64.c,v
retrieving revision 1.111
diff -p -r1.111 tc-ia64.c
*** tc-ia64.c	28 May 2004 19:26:31 -0000	1.111
--- tc-ia64.c	3 Jul 2004 22:42:18 -0000
*************** emit_one_bundle ()
*** 6129,6134 ****
--- 6129,6135 ----
    char mnemonic[16];
    fixS *fix;
    char *f;
+   int addr_mod;
  
    first = (md.curr_slot + NUM_SLOTS - md.num_slots_in_use) % NUM_SLOTS;
    know (first >= 0 & first < NUM_SLOTS);
*************** emit_one_bundle ()
*** 6160,6165 ****
--- 6161,6174 ----
  
    f = frag_more (16);
  
+   /* Check to see if this bundle is at an offset that is a multiple of 16-bytes
+      from the start of the frag.  */
+   addr_mod = frag_now_fix () & 15;
+   if (frag_now->has_code && frag_now->insn_addr != addr_mod)
+     as_bad (_("instruction address is not a multiple of 16"));
+   frag_now->insn_addr = addr_mod;
+   frag_now->has_code = 1;
+ 
    /* now fill in slots with as many insns as possible:  */
    curr = first;
    idesc = md.slot[curr].idesc;
Index: tc-ia64.h
===================================================================
RCS file: /cvs/src/src/gas/config/tc-ia64.h,v
retrieving revision 1.34
diff -p -r1.34 tc-ia64.h
*** tc-ia64.h	3 Mar 2004 19:26:26 -0000	1.34
--- tc-ia64.h	3 Jul 2004 22:42:18 -0000
*************** extern void ia64_convert_frag (fragS *);
*** 158,163 ****
--- 158,171 ----
  #define TC_FRAG_TYPE			int
  #define TC_FRAG_INIT(FRAGP)		do {(FRAGP)->tc_frag_data = 0;}while (0)
  
+ /* Give an error if a frag containing code is not aligned to a 16 byte
+    boundary.  */
+ #define md_frag_check(FRAGP) \
+   if ((FRAGP)->has_code							\
+       && (((FRAGP)->fr_address + (FRAGP)->insn_addr) & 15) != 0)	\
+      as_bad_where ((FRAGP)->fr_file, (FRAGP)->fr_line,			\
+ 		   _("instruction address is not a multiple of 16"));
+ 
  #define MAX_MEM_FOR_RS_ALIGN_CODE  (15 + 16)
  
  #define WORKING_DOT_WORD	/* don't do broken word processing for now */

RE: gas/ia64 "data in a code section" problem

[Belochapka, Konstantin]

This is really a good solution that would satisfy almost everyone. 

-----Original Message-----
From: Jim Wilson [mailto:wilson@specifixinc.com]
Sent: 03 July 2004 17:38
To: Belochapka, Konstantin
Cc: binutils@sources.redhat.com
Subject: RE: gas/ia64 "data in a code section" problem


On Tue, 2004-06-29 at 22:40, Belochapka, Konstantin wrote:
> Of course I agree that if anyone puts a data into code segment does this at his own risk. But my point is that an assembler also should not any restriction based on assumption of any potential problem. 
> The situation when IA64 assembler starts next bundle from an address that is not aligned on 16 bytes
> in my opinion is a bug that need to be corrected or it might be mentioned in a README file that after a data .align 16 directive is a requirement. But emitting error message would be not good solution, warning might be more appropriate.

A similar problem was reported against the PowerPC assembler a few days
ago.  See binutils bug 248.
    http://sources.redhat.com/bugzilla/show_bug.cgi?id=248
A patch was added that generates an error for misaligned PPC
instructions.
    http://sources.redhat.com/ml/binutils/2004-07/msg00017.html

I added a patch so we get the same error for misaligned IA-64
instructions.  It is attached.  You will need the above referenced patch
for this one to work.  This should make it easier to identify places
where you need to emit an alignment directive.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com