From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26705 invoked by alias); 11 Jul 2002 18:10:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26697 invoked from network); 11 Jul 2002 18:10:33 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 11 Jul 2002 18:10:33 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g6BIAWk08542 for ; Thu, 11 Jul 2002 11:10:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 11 Jul 2002 11:09:51 -0700 Received: from localhost (inghji.apple.com [17.201.22.240]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g6BIASl02738; Thu, 11 Jul 2002 11:10:28 -0700 (PDT) Date: Thu, 11 Jul 2002 11:42:00 -0000 Subject: Re: [patch] Fix to processing end of function stab in dbxread.c Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v533) Cc: gdb-patches@sources.redhat.com To: Daniel Jacobowitz From: Jim Ingham In-Reply-To: <20020711034619.GA22631@nevyn.them.org> Message-Id: <7B09F01E-94F9-11D6-AD3A-00039379E320@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00235.txt.bz2 Daniel, We are talking about two different things here - I am talking about converting the value in the blank FUN stab that marks the end of a function to a read address, NOT correcting an SLINE stab. That may seem confusing given that I was talking about linetables, so I will give my previous explanation in a little more detail. What is happening is that Fred was trying to work around the problem that SLINE's only give the start of the region of code assigned to that source line. You rely on the next SLINE to get the end. However, you can't always rely on the last line in a function to be properly terminated by a reasonable SLINE stab. For instance MacOS X's linker will coalesce all the out-of-line copies of an inlined function, or of lots of the compiler generated C++ goop, and shove them in a separate segment at the end of the text section. When it does that it updates all the various debug output. So we end up with something like (StrLength here was an inlined function): 0001abcc - 01 0099 SLINE 0001abf0 - 01 009c SLINE 0001abfc - 01 009d SLINE 0001ac08 - 01 009f SLINE 0001ac20 - 01 00a0 SLINE 0001ac30 - 01 00a2 SLINE 0001ac5c - 01 00a3 SLINE 0001ac88 - 01 00a4 SLINE 0001abcc - 01 0099 FUN _Z14GetPictureSizesPlS_:f(1,1) 00000078 - 00 0099 PSYM resID:p(1,145) 0000007c - 00 0099 PSYM height:p(1,260)=*(1,81) 00000080 - 00 0099 PSYM width:p(1,260) 00000040 - 00 009a LSYM picture:(1,171) 0001abf0 - 01 0000 LBRAC 0001ac88 - 01 0000 RBRAC 000000d0 - 00 0000 FUN 00031fd4 - 0c 0000 SOL /System/Library/Frameworks/CoreServices.framework/Headers/../ Frameworks/CarbonCore.framework/Headers/MacTypes.h 00031fd4 - 0c 019c SLINE 00031fe4 - 0c 019c SLINE 00031fd4 - 0c 019c FUN StrLength:F(1,73) 00000048 - 00 019c PSYM string:p(1,261)=(1,262)=*(1,263)=k(1,73) 00000000 - 00 0194 LSYM ConstStr255Param:t(1,261) 0000002c - 00 0000 FUN Now line 0xa4 is going to stretch from 0001ac88 to 00031fd4. Bad, bad, bad... Fred's fix was to emit a fake linetable entry - with linenumber 0, when he sees the end of function stab. That way, in the linetable there is just a region with no associated linenumbers from the end of the function to 00031fd4. The problem was getting "the end of the function" from the data in the null FUN stab. The value of the stab is the offset from the beginning of the function. He was adding that to function_start_offset which according to the comment in the file is NOT the address of the last function on any system but Solaris. It is the offset to the text section on other platforms, (which is clever, because then it is the correct thing to use to relocate the addresses in the SLINE entries on all platforms). But it is not an appropriate thing to add to the offset from the end function stab. Note also that in the one other place where we get the real address from the end fun stab (dbxread.c around 1726), we do: /* See if this is an end of function stab. */ if (pst && nlist.n_type == N_FUN && *namestring == '\000') { CORE_ADDR valu; /* It's value is the size (in bytes) of the function for function relative stabs, or the address of the function's end for old style stabs. */ valu = nlist.n_value + last_function_start; if (TEXTHIGH (pst) == 0 || valu > TEXTHIGH (pst)) TEXTHIGH (pst) = valu; break; } again using last_function_start, not function_start_offset. Jim On Wednesday, July 10, 2002, at 08:46 PM, Daniel Jacobowitz wrote: > On Wed, Jul 10, 2002 at 07:08:16PM -0700, Jim Ingham wrote: >> Index: dbxread.c >> =================================================================== >> RCS file: /cvs/src/src/gdb/dbxread.c,v >> retrieving revision 1.33 >> diff -c -w -r1.33 dbxread.c >> *** dbxread.c 10 May 2002 07:32:50 -0000 1.33 >> --- dbxread.c 11 Jul 2002 01:58:29 -0000 >> *************** >> Hi, all... >> >> Fred added an extra record_line call which closes off the last SLINE >> in >> a function when we come across the end of function N_FUN stab. This >> was a good thing, but unfortunately, he used function_start_offset, >> which on most systems is just the offset to the TEXT section (the >> exception being Solaris, where is actually is the real function >> start). >> He really meant to use last_function_start, which is the real address >> of the last N_FUN stab seen. >> >> I also fixed the comment before sline_found_in_function to accord with >> its current usage, since the old comment is wrong. We set >> sline_found_in_function = 0 at the same time we set >> last_function_start, but then we set it to 1 when we see the FIRST >> SLINE in a function, but last_function_start is still good after that. >> And nobody ever checks it to see if they should use >> last_function_start >> or not... > > Well, the archeology is hardly correct. I added both > last_function_start and sline_found_in_function recently; > last_function_start was because I couldn't convince myself that I could > trust the other. Note that in the normal N_SLINE handling, we use > function_start_offset and not last_function_start. So if your change > was really correct then all the N_SLINEs for your function would be in > the wrong places too. > > Could you please explain what problem you're trying to fix, and support > it with some stabs dumps? > >> >> *** 2761,2768 **** >> static CORE_ADDR last_function_start; >> >> /* If this is nonzero, we've seen an N_SLINE since the start of >> the >> current >> ! function. Initialized to nonzero to assure that >> last_function_start >> ! is never used uninitialized. */ >> static int sline_found_in_function = 1; >> >> /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this >> source >> --- 2761,2768 ---- >> static CORE_ADDR last_function_start; >> >> /* If this is nonzero, we've seen an N_SLINE since the start of >> the >> current >> ! function. We use this to tell us to move the first sline to >> the >> beginning >> ! of the function regardless of what its given value is. */ >> static int sline_found_in_function = 1; >> >> /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this >> source >> *************** >> *** 2799,2805 **** >> { >> /* This N_FUN marks the end of a function. This closes off >> the >> current block. */ >> ! record_line (current_subfile, 0, function_start_offset + >> valu); >> within_function = 0; >> new = pop_context (); >> >> --- 2799,2805 ---- >> { >> /* This N_FUN marks the end of a function. This closes off >> the >> current block. */ >> ! record_line (current_subfile, 0, last_function_start + >> valu); >> within_function = 0; >> new = pop_context (); >> >> Jim >> -- >> Jim Ingham jingham@apple.com >> Developer Tools - gdb >> Apple Computer >> >> > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer > -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer