From: Randolph Chung <randolph@tausq.org>
To: gdb-patches@sources.redhat.com
Subject: [patch] fix unwind handling on hppa elf targets
Date: Sat, 10 Apr 2004 09:02:00 -0000 [thread overview]
Message-ID: <20040410094328.GA31873@tausq.org> (raw)
This patch adds some infrastructure to make the generic hppa-tdep code
more sharable with hppa-linux. The unwind offset calculation is
applicable to all hppa-elf targets and not only on 64-bit targets.
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).
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/
next reply other threads:[~2004-04-10 9:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-10 9:02 Randolph Chung [this message]
2004-04-10 16:57 ` Joel Brobecker
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=20040410094328.GA31873@tausq.org \
--to=randolph@tausq.org \
--cc=gdb-patches@sources.redhat.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