From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25494 invoked by alias); 2 Apr 2006 13:37:09 -0000 Received: (qmail 25480 invoked by uid 22791); 2 Apr 2006 13:37:08 -0000 X-Spam-Check-By: sourceware.org Received: from chello212017098056.surfer.at (HELO hofr.at) (212.17.98.56) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 02 Apr 2006 13:37:07 +0000 Received: (from root@localhost) by hofr.at (8.10.2/Hofrat's Mail Service V2.2.8bet6-test1) id k33DnEk24211; Mon, 3 Apr 2006 15:49:14 +0200 From: Der Herr Hofrat Message-Id: <200604031349.k33DnEk24211@hofr.at> Subject: Re: /gdb/regcache.c question In-Reply-To: <200604021244.k32CiRXZ029528@elgar.sibelius.xs4all.nl> from Mark Kettenis at "Apr 2, 2006 02:44:27 pm" To: Mark Kettenis Date: Sun, 02 Apr 2006 13:37:00 -0000 CC: der.herr@hofr.at, gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00005.txt.bz2 > > From: Der Herr Hofrat > > Date: Mon, 3 Apr 2006 09:57:43 +0200 (CEST) > > > > Hi ! > > > > while implementing tracepoints I ran acros a little problem with > > gdb/regcache.c - the behavior is not really an error its just overly > > strict for interactive input, obviously regache.c is assuming > > automatic generation of registers lists only. > > > > (gdb) actions > > Enter actions for tracepoint 1, one per line. > > End with a line saying just "end". > > > collect $regs > > > end > > (gdb) trace junk2 > > Tracepoint 2 at 0x80483eb: file hello.c, line 27. > > (gdb) actions > > Enter actions for tracepoint 2, one per line. > > End with a line saying just "end". > > > collect $sp > > regcache.c:163: internal-error: register_type: Assertion `regnum >= 0 && regnum > > < descr->nr_cooked_registers' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Quit this debugging session? (y or n) n > > > > regcache.c:163: internal-error: register_type: Assertion `regnum >= 0 && regnum > > < descr->nr_cooked_registers' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Create a core file of GDB? (y or n) y > > > > > > The trigger is gdb_assert in line 163: > > > > gdb/regcache.c:159-165 > > struct type * > > register_type (struct gdbarch *gdbarch, int regnum) > > { > > struct regcache_descr *descr = regcache_descr (gdbarch); > > gdb_assert (regnum >= 0 && regnum < descr->nr_cooked_registers); > > return descr->register_type[regnum]; > > } > > > > > > So a simple misstyp of the register name runs into an assertion > > with a core file dumped - this makes sense for automatic generation > > - but for tracepoints you need to manually be able to pass > > registers with collect $REGNAME , and for that case gdb_assert -> > > corfile is a little harsh on the user. > > I don't understand what you're doing here, but that gdb_assert (and > all gdb_asserts in the code) is checking for a "should not happen" > condition. If you hit one, it means there's a bug in some other piece > of gdb code. You should find and fix that bug. > the bug is a simple typo in a collect command - if you type in $pc on x86 it will give you the above assertion if you use any actually defined registers all is fine (and data is collected) My assumption is that the assertion was put in there to catch incorrect register names that are generated automatically, but not interactively. hofrat