Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix unwind handling on hppa elf targets
Date: Sat, 10 Apr 2004 16:57:00 -0000	[thread overview]
Message-ID: <20040410165744.GH1114@gnat.com> (raw)
In-Reply-To: <20040410094328.GA31873@tausq.org>

> 2004-04-10  Randolph Chung  <tausq@debian.org>
> 
> 	* hppa-tdep.h (gdbarch_tdep): Add is_elf flag.
> 	* hppa-hpux-tdep.c (hppa_hpux_elf_init_abi): Set is_elf flag.
> 	* hppa-tdep.c (record_text_segment_lowaddr): Calculate text segment
> 	address using file offset.
> 	(internalize_unwinds): Predicate unwind offset calculation on is_elf
> 	flag rather than on width of binary. Remove "hokey" text segment
> 	masking (it is indeed wrong).

It looks like the value of is_elf is undefined in the case of hppa32-hpux.
I think you need to set it to zero in hppa_gdbarch_init().

I'd like to be given some time to test this patch on hppa32 and hppa64
before this gets checked in. Would that be ok?

> 
> Index: hppa-tdep.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 hppa-tdep.h
> --- hppa-tdep.h	15 Aug 2003 23:02:03 -0000	1.1
> +++ hppa-tdep.h	10 Apr 2004 08:50:20 -0000
> @@ -21,10 +21,13 @@
>  #ifndef HPPA_TDEP_H
>  #define HPPA_TDEP_H
>  
>  /* Target-dependent structure in gdbarch.  */
>  struct gdbarch_tdep
>  {
>    /* The number of bytes in an address.  For now, this field is designed
>       to allow us to differentiate hppa32 from hppa64 targets.  */
>    int bytes_per_address;
> +
> +  /* Is this an ELF target? This can be 64-bit HP-UX, or 32/64-bit Linux */
> +  int is_elf;
>  };
> Index: hppa-hpux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 hppa-hpux-tdep.c
> --- hppa-hpux-tdep.c	8 Apr 2004 21:18:12 -0000	1.14
> +++ hppa-hpux-tdep.c	10 Apr 2004 08:50:20 -0000
> @@ -727,6 +727,9 @@ hppa_hpux_som_init_abi (struct gdbarch_i
>  static void
>  hppa_hpux_elf_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +
> +  tdep->is_elf = 1;
>    hppa_hpux_init_abi (info, gdbarch);
>  }
>  
> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 hppa-tdep.c
> --- hppa-tdep.c	6 Apr 2004 16:11:02 -0000	1.142
> +++ hppa-tdep.c	10 Apr 2004 08:50:20 -0000
> @@ -360,10 +360,14 @@ static CORE_ADDR low_text_segment_addres
>  static void
>  record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
>  {
> -  if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
> +  if ((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
>         == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
> -      && section->vma < low_text_segment_address)
> -    low_text_segment_address = section->vma;
> +    {
> +      bfd_vma value = section->vma - section->filepos;
> +
> +      if (value < low_text_segment_address)
> +          low_text_segment_address = value;
> +    }
>  }
>  
>  static void
> @@ -381,22 +385,18 @@ internalize_unwinds (struct objfile *obj
>  
>        low_text_segment_address = -1;
>  
> -      /* If addresses are 64 bits wide, then unwinds are supposed to
> +      /* For ELF targets, then unwinds are supposed to
>  	 be segment relative offsets instead of absolute addresses. 
>  
>  	 Note that when loading a shared library (text_offset != 0) the
>  	 unwinds are already relative to the text_offset that will be
>  	 passed in.  */
> -      if (TARGET_PTR_BIT == 64 && text_offset == 0)
> +      if (gdbarch_tdep (current_gdbarch)->is_elf && text_offset == 0)
>  	{
>  	  bfd_map_over_sections (objfile->obfd,
>  				 record_text_segment_lowaddr, NULL);
>  
> -	  /* ?!? Mask off some low bits.  Should this instead subtract
> -	     out the lowest section's filepos or something like that?
> -	     This looks very hokey to me.  */
> -	  low_text_segment_address &= ~0xfff;
> -	  text_offset += low_text_segment_address;
> +	  text_offset = low_text_segment_address;
>  	}
>  
>        bfd_get_section_contents (objfile->obfd, section, buf, 0, size);
> -- 
> Randolph Chung
> Debian GNU/Linux Developer, hppa/ia64 ports
> http://www.tausq.org/

-- 
Joel


  reply	other threads:[~2004-04-10 16:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-10  9:02 Randolph Chung
2004-04-10 16:57 ` Joel Brobecker [this message]
2004-04-10 17:00   ` Randolph Chung
2004-04-10 17:20     ` Joel Brobecker
2004-04-10 17:25       ` Randolph Chung
2004-04-12  1:19         ` Joel Brobecker
2004-04-12  1:26           ` Randolph Chung

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=20040410165744.GH1114@gnat.com \
    --to=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=randolph@tausq.org \
    /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