From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26206 invoked by alias); 2 Apr 2006 07:45:37 -0000 Received: (qmail 26198 invoked by uid 22791); 2 Apr 2006 07:45:36 -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 07:45:35 +0000 Received: (from root@localhost) by hofr.at (8.10.2/Hofrat's Mail Service V2.2.8bet6-test1) id k337vhj22619 for gdb@sourceware.org; Mon, 3 Apr 2006 09:57:43 +0200 From: Der Herr Hofrat Message-Id: <200604030757.k337vhj22619@hofr.at> Subject: /gdb/regcache.c question To: gdb@sourceware.org Date: Sun, 02 Apr 2006 07:45:00 -0000 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/msg00003.txt.bz2 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. So the question is if it is sensible to change all the gdb_assert - which are the right way for automatic generated register lists, or if it would be better to distinuish between interactive and automatic generation. For the later I was trying to figure out a resonable way to know in what context this (and other functions) are called - but did not come up with any obvious solution yet - hacking it up only for the "collect" command makes no sense in my opinion. any suggestions how to handle this would be appreciated. thx ! hofrat