This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Porting GDB to ia64-hpux
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 28 Dec 2010 08:42:58 +0400
- Subject: Porting GDB to ia64-hpux
At long last, after having promised this a long time ago (this brings
memories of Australia, as I was spending time there when I first started
on this port), I am finally contributing this port. It took a while,
because the first port I did (against GDB 6.3) had a few hacks in it
that I wasn't happy about.
This port is relatively clean, I believe. There is one dark spot with
shared library support, which is currently native-only - if you build
GDB as a cross debugger to ia64-hpux, you won't get the shared libraries.
I think that this is an acceptable limitation, since I'm not planning on
supporting gdbserver-style remote debugging capabilities. I did spend
a couple of hours exploring the idea of using solib-target, but there
were a couple of issues[1].
I was able to build tcl/expect on this platform, and thus was able to
run the testsuite. Results are not stellar, but to my surprise, already
better than what I get on ia64-linux. A large portion of the failures
are caused by known limitations / missing features in that port, which
I will detail a little bit below. Results first:
# of expected passes 10618
# of unexpected failures 727
# of expected failures 50
# of untested testcases 105
# of unresolved testcases 12
# of unsupported tests 61
The entire patch series has also been tested on ia64-linux, with no
observed regression.
I'd like to commit this Thu or Fri in a week from now.
Known problems and missing features that are causing most of the failures:
- core files are not supported (I know it's easy to add, but I just
don't know how to!). If someone kindly helped, I would be happy
to give it a crack - an interesting learning exercise.
- The kernel on HP-UX does not allow the debugger to change the value
of the BSP register, which makes it impossible to "pop" a register
frame at the same time was pop the stack frame during a "return".
This pretty much guaranties great chaos during a "return" (loss of
synchronization between the call stack and the register stack).
- Backtraces through signal handlers.
- function-call parameter passing / return values: There are still
some cases where we pass the parameters incorrectly. But that's
general to ia64, I think.
--
Joel
[1] Issues related to using solib-target with ia64-hpux:
(a) I need the various hooks to setup the shared-lib notifications;
(b) And next, it's not obvious how to map the info I get from
the system back to the way the info is encoded in the
TARGET_OBJECT_SHARED_LIBRARIES object. In particular, there are
two segments (data and code) to consider when performing section
relocation. The second issue should be workable, but the first
one is a bit more of an issue.