debugger 6.2.1 misfeatures

debugger 6.2.1 misfeatures

[Edward Peschko]

hey all,

For some reason, gdb-6.2.1 isn't reading symbols when it attaches to processes..
gdb-5.3 has no problem doing this. (installed on sun solaris 2.8)


Is this an oversight - or a potential bug? If a bug, what diagnostic input do 
people need in order to track it down?

Thanks,

Ed

Re: debugger 6.2.1 misfeatures

[Michael Chastain]

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

RE: debugger 6.2.1 misfeatures

[Monika Chaddha]

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

Re: debugger 6.2.1 misfeatures

[Michael Chastain]

"Monika Chaddha" <monika@acmet.com> wrote:
> Is it necessary to send test cases with the bug?

Depends on the bug.  It's necessary to send enough info for someone
else to reproduce 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.

First check the file sim/MAINTAINERS and make sure you're sending
to the specific maintainer as well as gdb-patches@.

Post.  Wait a week, then send it again with a note indicating that it's
a repost, with the dates of the previous post.  Wait another week, do it
again (with all the previous dates).  Wait another week, do it again.
Wait another week, do it again.  Wait another week, do it again.

After a month of this, start a separate thread asking for an additional
maintainer for the area that you're patching.

The longest I've had to wait this year has been 125 days.

Michael Chastain
honor fdny -- give blood

RE: debugger 6.2.1 misfeatures

[Monika Chaddha]

>First check the file sim/MAINTAINERS and make sure you're sending
>to the specific maintainer as well as gdb-patches@.
>

Thanks for the info, 
I was not sending to specific maintainer and sending to gdb-patches
only.

Regards 
Monika

Re: debugger 6.2.1 misfeatures

[Joel Brobecker]

> For some reason, gdb-6.2.1 isn't reading symbols when it attaches to
> processes..  gdb-5.3 has no problem doing this. (installed on sun
> solaris 2.8)
> 
> Is this an oversight - or a potential bug? If a bug, what diagnostic
> input do people need in order to track it down?

This is pretty easy to reproduce. I took a program that was looping
for ever, and attached to it. The symbols where indeed not loaded.
For instance, take attach.c from attach.exp, launch it, then use
GDB to attach to it, and you'll see the problem.

Interestingly, this seems to be solaris-specific, as the problem
doesn't appear on x86-linux for instance.

This shouldn't be very hard to fix. I'd rather continuing my work
on the mips-irix port, but if nobody has taken ownership of this
problem by tonight, I'll have a quick look.

-- 
Joel

Re: debugger 6.2.1 misfeatures

[Joel Brobecker]

> This is pretty easy to reproduce. I took a program that was looping
> for ever, and attached to it. The symbols where indeed not loaded.
> For instance, take attach.c from attach.exp, launch it, then use
> GDB to attach to it, and you'll see the problem.
> 
> Interestingly, this seems to be solaris-specific, as the problem
> doesn't appear on x86-linux for instance.
> 
> This shouldn't be very hard to fix. I'd rather continuing my work
> on the mips-irix port, but if nobody has taken ownership of this
> problem by tonight, I'll have a quick look.

On second thoughts, I decided not to look into this. I'm plenty busy
with the mips cleanup right now, and this issue is easily worked around
(use "file" command to get the symbols) while the mips debugger really
is badly broken.

I recommend that a PR be filed, and the problem be documented. Maybe
somebody else will find an hour or two to look into this.

-- 
Joel