This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: debugger 6.2.1 misfeatures
- From: "Monika Chaddha" <monika at acmet dot com>
- To: "'Michael Chastain'" <mec dot gnu at mindspring dot com>, <gdb at sources dot redhat dot com>
- Date: Sat, 11 Sep 2004 15:26:43 +0530
- Subject: RE: debugger 6.2.1 misfeatures
Is it necessary to send test cases with the bug? I had sent the
following bug with patch some days ago but didn't get any response
regarding this. I don't have any test case till now to prove this bug as
it can be test only for remote target during tracing.
What should I do? Pls help.
Thanks & Regards
Monika
Defect report:-
-------------
File
-----
/src/sim/mips/m16.igen
Defects
--------
1. Mnemonic for CMP instruction is putted as
"sltiu r<TRX>, r<TRY>"
While it should be as
"cmp r<TRX>, r<TRY>"
2. Mnemonic for CMPI instruction is putted as
"sltiu r<TRX>, <IMMED>"
While it should be as
"cmpi r<TRX>, <IMMED>"
Patch
-----
GDB Version no: 6.0
File: /src/sim/mips/m16.igen
11101,3.RX,3.RY,01010:RR:16::CMP
-"sltiu r<TRX>, r<TRY>"
+"cmp r<TRX>, r<TRY>"
*mips16:
*vr4100:
{
do_xor (SD_, TRX, TRY, T8IDX);
}
01110,3.RX,8.IMMED:RI:16::CMPI
-"sltiu r<TRX>, <IMMED>"
+"cmpi r<TRX>, <IMMED>"
*mips16:
*vr4100:
{
do_xori (SD_, TRX, T8IDX, IMMED);
}
>-----Original Message-----
>From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com] On
>Behalf Of Michael Chastain
>Sent: Saturday, September 11, 2004 7:17 AM
>To: gdb@sources.redhat.com; esp5@pge.com
>Subject: Re: debugger 6.2.1 misfeatures
>
>Sounds like a bug to me.
>
>Generally for a bug, we need:
>
> the gdb version
> the host operating system version
> the target operating system version (if it's not the same as the
host)
> a typescript of the whole gdb session showing the bug
> (use the 'script' command)
> some info about the inferior program:
> what language it's written in
> the exact compiler name and compiler version that it was built with
>
>Then if somebody picks up the bug, they're likely to come back with
>more questions. The point at this stage is not to identify the bug,
>but just to throw enough information over the fence so that the
>gdb engineer can *reproduce* the bug.
>
>If it worked with a previous version of gdb, that's good to know.
>
>It's really great if you can supply a small test program
>(source + binary) that demonstrates the bug.
>
>And some bug reports are successful and get fixed, and some aren't
>and don't.
>
>Michael Chastain