Re: [RFA/RFC] mips tracepoint: fix Bug 12013

Hui Zhu
2010-12-19T12:16:29Z

On Sun, Dec 19, 2010 at 18:39, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> From: Hui Zhu <teawater@gmail.com>
>> Date: Sun, 19 Dec 2010 16:35:59 +0800
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12013
>>
>> This bug make mips tracepoint cannot trace the backtrace.
>>
>> This patch to fix this issue with a directly way just remove the
>> decline of access to the raw register names.
>>
>> If you think it's not OK.  What about add a new interface to gdbarch
>> to access to the raw register names.
>
> It is a common trick to return an empty register name for a (raw)
> register to hide the register from the user.  So I don't think this
> diff is ok, since the goal obviously is to hide the raw registers in
> mips in favour of the pseudo registers.

Could you tell me what this hide for? I didn't find who get some
advantage form this part?

>
> I'd say the proper way forward is to teach the trace code to handle
> pseudo registers.

void
regcache_cooked_read (struct regcache *regcache, int regnum, gdb_byte *buf)
{
gdb_assert (regnum >= 0);
gdb_assert (regnum < regcache->descr->nr_cooked_registers);
if (regnum < regcache->descr->nr_raw_registers)
regcache_raw_read (regcache, regnum, buf);
else if (regcache->readonly_p
&& regnum < regcache->descr->nr_cooked_registers
&& regcache->register_valid_p[regnum])
/* Read-only register cache, perhaps the cooked value was cached? */
memcpy (buf, register_buffer (regcache, regnum),
regcache->descr->sizeof_register[regnum]);
else
gdbarch_pseudo_register_read (regcache->descr->gdbarch, regcache,
regnum, buf);
}

For now, even if gdb doesn't how to handle pseudo, it put it to
gdbarch. I need add a new interface to gdbarch to handle it if we
really need.

Thanks,
Hui

>
>> 2010-12-19  Hui Zhu  <teawater@gmail.com>
>>
>>       * mips-tdep.c (mips_register_name): Remove the check.
>>       (mips_print_registers_info): Remove the gdb_assert.
>>
>