From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7545 invoked by alias); 2 Mar 2003 06:52:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7538 invoked from network); 2 Mar 2003 06:52:01 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 2 Mar 2003 06:52:01 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h226px701731; Sun, 2 Mar 2003 00:51:59 -0600 Date: Sun, 02 Mar 2003 06:52:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200303020651.h226px701731@duracef.shout.net> To: kettenis@chello.nl Subject: Re: 8-byte register values on a 32-bit machine Cc: brobecker@gnat.com, gdb@sources.redhat.com X-SW-Source: 2003-03/txt/msg00021.txt.bz2 mec> I understand that on some targets, gcc and gdb might agree on register mec> number allocation (ignore for the moment that there are other compilers mec> besides gcc). Okay, for targets where we have a guarantee about that, mec> then enable sequential register access. But i686-pc-linux-gnu is mec> definitely not such a target. mark> I don't agree with the defenitely here. GCC has been allocating the mark> registers in a well determined order for at least 10 years now. Ah, yeah, I am saying that gcc and gdb disagree on the register number ordering, and you are saying that gcc has a well determined order -- so in principle gdb could know that order and follow it. I think both statements are true. This test worked for months and then regressed recently. gdb's code recently changed from "iterate over some registers" (which worked for this test case, at least, but is not guaranteed to work all the time). Then this patch happened: 2003-02-21 Daniel Jacobowitz Based on a patch from Daniel Berlin (dberlin@dberlin.org) ... * dwarf2expr.c, dwarf2expr.h, dwarf2loc.c, dwarf2loc.h: New files. ... Before this patch, the dwarf2 reader would mark these as LOC_REGISTER and value_from_register would loop over the # of registers that are needed. This is the case we are talking about, where gdb and the compiler in use might or might not match on the register assignments. After this patch, (that is, in today's gdb), the dwarf2 reader marks the multi-register expression as LOC_COMPUTED. Then dwarf2_evaluate_loc_desc calls store_unsigned_integer just once, *no matter how large the size is*. I've seen this happen by debugging gdb running on my test program (build testsuite/gdb.base/store.exp with gcc 2.95.3 -gdwarf-2). gdb doesn't even try to read any other registers. So if the location is "register %eax, size 8", gdb does not even look in %edx. I don't know exactly where gdb gets bytes 4-7 of the data. I %suspect it's just using uninitialized buffer contents. That's what I %really meant about gdb pulling values "out of its ass". Also I apologize for that phrase. I think it's accurate for what gdb is doing right now with, but I didn't share that knowledge about dwarf2_evaluate_loc_desc, and it's kind of inflammatory to say that for register orders. Plus it's disrespectful to the developers which is the real problem. Obviously this is work in progress and that's what CVS is for, and that's what regression testing is for. Anyways, I think there are two problems here: (1) dwarf2_evaluate_loc_desc is getting called with ctx->in_reg=true and size=8. I need to provide an actual test executable to show this happening. When this happens, dwarf2_evaluate_loc_desc just reads *1* register. This is definitely wrong (if my description of gdb's behavior is accurate). (2) We have to decide what gdb will do in various cases. As I've mentioned, I'm hostile to the idea of gdb intuiting the register order. If there is no list of registers is not as long as the data size then I would rather that gdb print "" for the unknown ones. But I recognize that's up to the symtab maintainers to decide. Thanks for listening to my input. Michael C