public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sje@cup.hp.com>
To: binutils@sources.redhat.com
Cc: davidm@hpl.hp.com
Subject: [PATCH] Make debug info section relative on IA64
Date: Thu, 27 Feb 2003 21:11:00 -0000	[thread overview]
Message-ID: <200302272111.NAA23312@hpsje.cup.hp.com> (raw)

This is a change to make debug sections relative on IA64.  The person
who made this change isn't around anymore but here is her description of
the problem that this patch fixes, if this looks good could someone
check it in for me?

Steve Ellcey
sje@cup.hp.com

>     We are having a problem where GAS is putting in incorrect
> relocations for .debug_abbrev, .debug_info, and .debug_line
> when they are referenced as offsets.  This problem only happens
> with assembly files that contain no debug information and
> the file is assembled with GAS with the option --gdwarf2.
> In the object file, there will be debug information but the
> offsets which correspond to .debug_abbrev, .debug_info, and
> .debug_line will have relocations of DIR32MSB on HP-UX (and
> DIR64LSB on Linux).
> 
>     This severly confuses the HP linker when performing relocations
> and the result is an executable with cannot be debugged.   I spoke
> with someone on our Linker team and it looks like .debug_abbrev,
> .debug_info, and .debug_line should be section relative offsets
> (i.e. SECREL32MSB).   We fixed this once for 'C' files by forcing
> GCC to put out correct assembler directives to make these section
> relative offsets.  However, an assembly file with no debug information
> in it will not have these directives.  I made a code change in
> ia64_cons_fix_new()
> in tc-ia64.c which fixes this problem.


2003-02-27  Steve Ellcey  <sje@cup.hp.com>

	* config/tc-ia64.c: Make debug sections relative.


*** src.orig/gas/config/tc-ia64.c	Thu Feb 27 12:56:58 2003
--- src/gas/config/tc-ia64.c	Thu Feb 27 12:57:42 2003
*************** ia64_cons_fix_new (f, where, nbytes, exp
*** 10055,10063 ****
      case 2: code = BFD_RELOC_16; break;
      case 4:
        if (target_big_endian)
! 	code = BFD_RELOC_IA64_DIR32MSB;
        else
! 	code = BFD_RELOC_IA64_DIR32LSB;
        break;
  
      case 8:
--- 10055,10081 ----
      case 2: code = BFD_RELOC_16; break;
      case 4:
        if (target_big_endian)
! 	{
! 	  if (exp->X_op == O_symbol &&
! 	      exp->X_add_symbol &&
! 	      (!strcmp(S_GET_NAME(exp->X_add_symbol),".debug_abbrev") ||
! 	       !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_line") ||
! 	       !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_info")))
! 	    code = BFD_RELOC_IA64_SECREL32MSB;
! 	  else	
! 	    code = BFD_RELOC_IA64_DIR32MSB;
! 	}
        else
! 	{
! 	  if (exp->X_op == O_symbol &&
! 	      exp->X_add_symbol &&
! 	      (!strcmp(S_GET_NAME(exp->X_add_symbol),".debug_abbrev") ||
! 	       !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_line") ||
! 	       !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_info")))
! 	    code = BFD_RELOC_IA64_SECREL32LSB;
! 	  else	
! 	    code = BFD_RELOC_IA64_DIR32LSB;
! 	}
        break;
  
      case 8:
*************** ia64_cons_fix_new (f, where, nbytes, exp
*** 10086,10095 ****
  	}
        else
  	{
! 	  if (target_big_endian)
! 	    code = BFD_RELOC_IA64_DIR64MSB;
  	  else
! 	    code = BFD_RELOC_IA64_DIR64LSB;
  	  break;
  	}
  
--- 10104,10131 ----
  	}
        else
  	{
! 	  if (target_big_endian) 
! 	    {
! 	      if (exp->X_op == O_symbol &&
! 		  exp->X_add_symbol &&
! 		  (!strcmp(S_GET_NAME(exp->X_add_symbol),".debug_abbrev") ||
! 		   !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_line") ||
! 		   !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_info")))
! 		code = BFD_RELOC_IA64_SECREL64MSB;
! 	      else
! 		code = BFD_RELOC_IA64_DIR64MSB;
! 	    }
  	  else
! 	    {
! 	      if (exp->X_op == O_symbol &&
! 		  exp->X_add_symbol &&
! 		  (!strcmp(S_GET_NAME(exp->X_add_symbol),".debug_abbrev") ||
! 		   !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_line") ||
! 		   !strcmp(S_GET_NAME(exp->X_add_symbol),".debug_info")))
! 		code = BFD_RELOC_IA64_SECREL64LSB;
! 	      else
! 		code = BFD_RELOC_IA64_DIR64LSB;
! 	    }
  	  break;
  	}
  

             reply	other threads:[~2003-02-27 21:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-27 21:11 Steve Ellcey [this message]
2003-02-27 21:33 ` Daniel Jacobowitz
2003-02-28  1:33 ` Richard Henderson
2003-02-28 18:46   ` Steve Ellcey
2003-02-28 19:34     ` Richard Henderson
2003-03-07  1:16       ` Steve Ellcey
2003-03-11 21:54         ` Richard Henderson
2003-03-11 22:02         ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302272111.NAA23312@hpsje.cup.hp.com \
    --to=sje@cup.hp.com \
    --cc=binutils@sources.redhat.com \
    --cc=davidm@hpl.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).