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
next prev parent 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