Skip to contentSkip to conversation

gdb support for IA32?

Linux-ia64 Vadim Furman 4 participants 4 messages Mar 21, 2000 – Mar 22, 2000

lore
Share & tools
lore
#0 lore raw

Are there any plans to support gdb on IA32?
If so, when will it be available?

Vadim Furman Mainsoft Corporation
[email protected] Phone: (408)544-1430
Fax: (408)544-1444
3850 N. First St.
San Jose CA. 95134-1702

#1 lore raw

Are there any plans to support gdb on IA32? If so, when will it be available?

I don't think that is the question you meant to ask. gdb has had IA-32 (x86) linux support for many years.

gdb support for IA-64 already exists and is already available. The gdb support is not complete yet, but most basic commands already work.

If you want a ia32-linux cross ia64-linux gdb, then that is a harder question, as there is the issue of how to communicate between the ia32 and ia64 machines. If you can use gdbserver, then that may still work. It was used early in gdb development before the native ia64 gdb was working well. There are no plans to maintain this long term though, as it ceased being interesting once the native ia64 was working well enough to debug itself.

Jim

#2 lore raw
In reply to Vadim Furman

Vadim-

Funny you should ask. I've just started to do this. The ultimate goal would be to have a single gdb' that operates on either an IA64 or IA32 process. I think that would be a little tricky so I'm trying to just take the current gdb' sources, compile them on my IA64 machine and create a version of `gdb' that only works on IA32 processes running on IA64. Assuming I don't run into any show stopper problems I should have it up and running within about a week.

Quoted 15 lines · Vadim Furman

Are there any plans to support gdb on IA32?
If so, when will it be available?

Vadim Furman Mainsoft Corporation
[email protected] Phone: (408)544-1430
Fax: (408)544-1444
3850 N. First St.
San Jose CA. 95134-1702

_______________________________________________
Linux-IA64 mailing list
[email protected]
http://lists.linuxia64.org/lists/listinfo/linux-ia64

Signature · 4 lines
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/938-9838
#3 lore raw
In reply to Vadim Furman
Quoted 3 lines · Don Dugger

Funny you should ask. I've just started to do this. The ultimate goal would be to have a single `gdb' that operates on either an IA64 or IA32 process. I think that would be a little tricky

I agree that this is a desirable goal. But to achieve it the IA-32 port will have to be fully mult-arch'd first. (Since the IA-64 port is a brand new port, we were able to properly multi-arch it from the beginning.)

Quoted 5 lines

so I'm trying to just take the current gdb' sources, compile them on my IA64 machine and create a version of gdb' that only works on IA32 processes running on IA64. Assuming I don't run into any show stopper problems I should have it up and running within about a week.

Did you create a new ia64-linux-ia32-nat.c (or somesuch) file to fetch the registers and such?

Another way to approach this would be to write a ptrace() interface for IA-32 processes which provides the same functionality as the existing linux/x86 kernel. Then you could just take a gdb binary built for linux/x86 and it'd work. (Maybe.)

Other news from the gdb front...

- I've committed the IA-64 specific sources in the gdb tree to the CVS repository at sourceware.cygnus.com. We still need to get the binutils and opcodes sources committed, but Trillian members should be able to make use of this repository by fetching just the gdb tree from sourceware and using the binutils, opcodes, etc. from the last release. (Yes, this is less than optimal...)

- I've gotten the code for calling inferior functions working. In order to use it, you'll need to have my Mar 10 ptrace.c patches applied to your kernel.

- There have been a number of other small changes and bug fixes which should improve the usability of the debugger. E.g, when you do ``finish'', you'll now see the correct return value (so long as it's not an HFA). Also, the ``return'' command now works. Display of floating point values should now work much better provided you've fixed the __scalbn() compiler bug in your libc. (But there are changes to some of the generic gdb code for floats as well...)

- I am now able to run the gdb test suite. I am presently whittling away at the number of failures.

I can put a newer gdb binary up on bunyip if desired...

Kevin

Signature · 2 lines
Kevin Buettner
[email protected], [email protected]