From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: richard@brainstorm.co.uk Cc: GDB Discussion , Klee Dienes , Jim Ingham Subject: Re: GDB 5.1 TODO list Date: Wed, 02 Aug 2000 22:30:00 -0000 Message-id: <3989035E.3C5DA694@cygnus.com> References: <39877E58.2828D2B5@cygnus.com> <10008021015.AA03688@tiptree.brainstorm.co.uk> X-SW-Source: 2000-08/msg00024.html 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 To: Denis Perchine Cc: GDB Discussion 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" To: "GDB" 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 : 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 ...