From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3060 invoked by alias); 24 Jul 2010 01:04:30 -0000 Received: (qmail 2915 invoked by uid 22791); 24 Jul 2010 01:04:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_FD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 24 Jul 2010 01:04:25 +0000 Received: (qmail 30066 invoked from network); 24 Jul 2010 01:04:23 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jul 2010 01:04:23 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: RFC: change needs_frame_tls_address Date: Sat, 24 Jul 2010 01:04:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.31-11-rt; KDE/4.4.2; x86_64; ; ) Cc: Tom Tromey References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007240204.20661.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00379.txt.bz2 > For this we get a warning from value_static_field, then things go > downhill and we hit an internal_error. From the PR: (...) > After tracing through the TLS code for a bit, I have concluded that TLS > does not really need a frame, at least not in the gdb sense. Instead, I > think it only needs registers -- a funny sort of distinction to make, > but nevertheless... Given that if you have registers, you always have a frame, I don't think that's a good check. > (gdb) p A::num > $1 = 1 > (gdb) kill > Kill the program being debugged? (y or n) y > (gdb) p A::num > Cannot access memory at address 0xb7fdb6d8 Is that useful? It seems to be trying to print a bogus address. Actually, I'm surprised you even got that memory error instead of "Cannot find thread-local variables on this target", which is what I get on x86-64 (both -m64/-m32) with your change applied. Clearly gdb didn't try reading any register, otherwise, you would see some other error. Do you have other changes in your tree perhaps? > If it is not acceptable, I would appreciate some enlightenment as to > what other approach I should take. The warning seems bogus to me: > (gdb) print A::num > warning: static field's value depends on the current frame - bad debug info? > findvar.c:427: internal-error: read_var_value: Assertion `frame' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) I think we should throw an error instead, just like what you get when you try to print a non class static global TLS variable: __thread int global_num = 1; Both cases are the same in the user's perpective, so should behave equal. Trying to print `global_num' with no process/core throws an error in value_of_variable. I guess we should make value_static_field use value_of_variable instead of read_var_value directly too (or a factored out variant that doesn't throw if read_var_value returns NULL). -- Pedro Alves