This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, Jun 02, 2003 at 12:30:36PM -0400, Daniel Jacobowitz wrote:
Yes. I was a little surprised by the void_data_ptr/void_func_ptr bit, but I see that d10v does the same thing, so it must be right :)
(gdb) ptype $pc type = void (*)() (gdb) x/i $pc 0x10140b8 <main+20>: ld r0, @r11 || nop (gdb) print/x $pc $1 = 0x10140b8 (gdb) print/x (int)$pc $2 = 0x502e
Hmm, I'm not sure. Any particular reason for this patch?
Well, the void_func_ptr bit is nice because "info r" yields
pc 0x12000053c 0x12000053c <main+16>
The void_data_ptr bits I think just document which registers are ABI mandated to contain pointer values all of the time.
Actually, I have a related question here. Something that I
didn't notice earlier is that d10v is using register_type,
not register_virtual_type. Looking at the guts of regcache.c,
it would appear that the later is deprecated, since not having a register_type hook (among other things) results in
legacy_p being set.
I thought it obvious to rename my existing hook, but that changes the behaviour of "info r" -- I no longer get the pc decoded, and indeed "ptype $pc" once again yields int64_t.
Is this a bug elsewhere in gdb, or what?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |