Re: GDB 5.1 TODO list

[Andrew Cagney <ac131313@cygnus.com>]

richard@brainstorm.co.uk wrote:
> 
> On Wed, 02 Aug 2000 11:50:16 +1000, ac131313@cygnus.com wrote:
> > GDB 5.1 - New features
> > ======================
> 
> Shouldn't Objective-C support be on this list?

This is up to KleeD and JimI.  I'll put it down for definitly by 5.2
(which means it is nice to have for 5.1).

	Andrew
From ac131313@cygnus.com Wed Aug 02 22:39:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Denis Perchine <dyp@perchine.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 22:39:00 -0000
Message-id: <39890568.93E19471@cygnus.com>
References: <39877E58.2828D2B5@cygnus.com> <00080217420101.00568@dyp.perchine.com>
X-SW-Source: 2000-08/msg00025.html
Content-length: 824

Denis Perchine wrote:
> 
> > So here is a first cut at the things that are really on the 5.1 TODO
> > list.  In previous discussions it has been suggested that for each
> > release a small number of changes be identifed and completed (of course
> > everyone is activly encouraged to also work on any other TODO or
> > non-TODO items :-)
> 
> Is threads on Linux worked properly?
> In 5.0 there was real mess with them. It was impossible to debug MT programs.

MarkK has already noted a serious thread problem and fixing that has
gone on the list.

> * Thread support.  Right now, as soon as a thread finishes and exits,
>   you're hosed.  This problem is reported once a week or so.

One thing that is desparatly needed is a few good test cases.  It is
hard to tell if thread support is getting better or worse :-(

	Andrew
From gerwynd@tommoll.freeserve.co.uk Thu Aug 03 02:42:00 2000
From: "Gerwyn Davies" <gerwynd@tommoll.freeserve.co.uk>
To: "GDB" <gdb@sourceware.cygnus.com>
Subject: Disassembly difference
Date: Thu, 03 Aug 2000 02:42:00 -0000
Message-id: <008101bffd2f$8db67b20$1701883e@gtd-s-machine>
X-SW-Source: 2000-08/msg00026.html
Content-length: 1566

Hello,

I'm experiencing a difference in opinion between the disassembly produced by
objdump and that produced by GDB. As these two traces show. Can anyone offer
an explanation.

GDB TRACE:
This GDB was configured as "--host=i586-pc-cygwin32 --target=mips-tx39-elf".
(gdb) target remote com1
Remote debugging using com1
0xbfc09fbc in ?? ()
(gdb) load led.rom
Loading section .text, size 0xe34 lma 0xa0008000
Loading section .ctors, size 0x8 lma 0xa0020e34
Loading section .dtors, size 0x8 lma 0xa0020e3c
Loading section .data, size 0x720 lma 0xa0008e34
Loading section .sdata, size 0x1c lma 0xa0009554
Start address 0xa0020000 , load size 5504
Transfer rate: 1693 bits/sec.
(gdb) disas 0xa0020000 0xa0020030
Dump of assembler code from 0xa0020000 to 0xa0020030:
0xa0020000:     nop
0xa0020004:     sllv    $zero,$zero,$zero
0xa0020008:     0x2010000
0xa002000c:     lb      $zero,512($a0)
0xa0020010:     nop
0xa0020014:     nop
0xa0020018:     sll     $zero,$s0,0x0
0xa002001c:     0x1
0xa0020020:     0x10a001
0xa0020024:     nop
0xa0020028:     sll     $zero,$zero,0x8
0xa002002c:     nop
End of assembler dump.



OBJDUMP TRACE:
00000000a0020000 <_start>:
    a0020000: 00000000  nop

00000000a0020004 <zerobss>:
    a0020004: 3c02a004  lui $v0,0xa004
    a0020008: 2442073c  addiu $v0,$v0,1852
    a002000c: 3c03a004  lui $v1,0xa004
    a0020010: 24630850  addiu $v1,$v1,2128
    a0020014: ac400000  sw $zero,0($v0)
    a0020018: 24420004  addiu $v0,$v0,4
    a002001c: 0062082b  sltu $at,$v1,$v0
    a0020020: 1020fffc  beqz $at,a0020014 <zerobss+0x10>
 ...