This is the mail archive of the gdb-patches@sourceware.org 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]

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


On Tue, Dec 21, 2010 at 22:58, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> From: Hui Zhu <teawater@gmail.com>
>> Date: Tue, 21 Dec 2010 22:45:15 +0800
>>
>> Did not get any reason.
>
> ?
>
>> Checked in.
>
> I told you this is wrong. ?You'll have to fix this in a different way.
> I'm not familliar with the tracepoint stuff, so I can't really help
> you with that.

You didn't give me the reason.  I asked you:
>> > Could you tell me what this hide for? ?I didn't find who get some
>> > advantage form this part?

But you didn't answer.   I don't care you familliar with trace or not.

Do you familliar with MIPS?
If so, please answer me.  If not, please don't say anything.

Thanks,
Hui

>
> Please back this out immediately.
>
>> On Sun, Dec 19, 2010 at 20:15, Hui Zhu <teawater@gmail.com> wrote:
>> > 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.
>> >>>
>> >>
>> >
>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]