* coffread.c and one-line functions
1999-04-07 21:50 coffread.c and one-line functions Philippe De Muyter
@ 1999-04-07 22:49 ` Philippe De Muyter
1999-04-14 13:21 ` Stan Shebs
1 sibling, 0 replies; 4+ messages in thread
From: Philippe De Muyter @ 1999-04-07 22:49 UTC (permalink / raw)
To: gdb-patches
Thu Apr 8 06:26:12 1999 Philippe De Muyter <phdm@macqel.be>
* breakpoint.c (maintenance_info_breakpoints): Function made static
to match previous prototype.
* coffread.c (coff_record_line): Static function removed.
(enter_linenos): Call `record_line' instead of `coff_record_line'.
(FILE-LEVEL, coff_start_symtab, coff_end_symtab): `coff_record_line'
-related stuff removed.
(coff_symfile_read): Redundant statement removed.
(coff_symtab_read): `record_line' is now called with the first line
number of each function, given by the ".bf" symbol. This solves
the line-number bug for one-line functions.
--- ./breakpoint.c Thu Apr 8 06:21:55 1999
+++ ./breakpoint.c Wed Mar 31 01:06:39 1999
@@ -2935,7 +2935,7 @@ breakpoints_info (bnum_exp, from_tty)
#if MAINTENANCE_CMDS
/* ARGSUSED */
-void
+static void
maintenance_info_breakpoints (bnum_exp, from_tty)
char *bnum_exp;
int from_tty;
--- ./coffread.c Thu Apr 8 06:21:58 1999
+++ ./coffread.c Wed Apr 7 19:28:34 1999
@@ -84,21 +84,6 @@
static bfd *nlist_bfd_global;
static int nlist_nsyms_global;
-/* Vector of line number information. */
-
-static struct linetable *line_vector;
-
-/* Index of next entry to go in line_vector_index. */
-
-static int line_vector_index;
-
-/* Last line number recorded in the line vector. */
-
-static int prev_line_number;
-
-/* Number of elements allocated for line_vector currently. */
-
-static int line_vector_length;
/* Pointers to scratch storage, used for reading raw symbols and auxents. */
@@ -252,8 +237,6 @@
static void coff_start_symtab PARAMS ((char *));
-static void coff_record_line PARAMS ((int, CORE_ADDR));
-
static struct type *coff_alloc_type PARAMS ((int));
static struct type **coff_lookup_type PARAMS ((int));
@@ -440,30 +423,6 @@ coff_alloc_type (index)
return type;
}
\f
-/* Record a line number entry for line LINE at address PC.
- FIXME: Use record_line instead. */
-
-static void
-coff_record_line (line, pc)
- int line;
- CORE_ADDR pc;
-{
- struct linetable_entry *e;
- /* Make sure line vector is big enough. */
-
- if (line_vector_index + 2 >= line_vector_length)
- {
- line_vector_length *= 2;
- line_vector = (struct linetable *)
- xrealloc ((char *) line_vector, sizeof (struct linetable)
- + (line_vector_length
- * sizeof (struct linetable_entry)));
- }
-
- e = line_vector->item + line_vector_index++;
- e->line = line; e->pc = pc;
-}
-\f
/* Start a new symtab for a new source file.
This is called when a COFF ".file" symbol is seen;
it indicates the start of data for one original source file. */
@@ -484,17 +443,6 @@ coff_start_symtab (name)
last_source_start_addr in coff_end_symtab. */
0);
record_debugformat ("COFF");
-
- /* Initialize the source file line number information for this file. */
-
- if (line_vector) /* Unlikely, but maybe possible? */
- free ((PTR)line_vector);
- line_vector_index = 0;
- line_vector_length = 1000;
- prev_line_number = -2; /* Force first line number to be explicit */
- line_vector = (struct linetable *)
- xmalloc (sizeof (struct linetable)
- + line_vector_length * sizeof (struct linetable_entry));
}
/* Save the vital information from when starting to read a file,
@@ -535,26 +483,12 @@ coff_end_symtab (objfile)
last_source_start_addr = current_source_start_addr;
- /* For no good reason, this file stores the number of entries in a
- separate variable instead of in line_vector->nitems. Fix it. */
- if (line_vector)
- line_vector->nitems = line_vector_index;
-
- /* For COFF, we only have one subfile, so we can just look at
- subfiles and not worry about there being other elements in the
- chain. We fill in various fields now because we didn't know them
- before (or because doing it now is simply an artifact of how this
- file used to be written). */
- subfiles->line_vector = line_vector;
-
symtab = end_symtab (current_source_end_addr, objfile, 0);
if (symtab != NULL)
free_named_symtabs (symtab->filename);
/* Reinitialize for beginning of new file. */
- line_vector = 0;
- line_vector_length = -1;
last_source_file = NULL;
}
\f
@@ -683,7 +617,6 @@ coff_symfile_read (objfile, section_offs
/* Set a few file-statics that give us specific information about
the particular COFF file format we're reading. */
- local_linesz = cdata->local_linesz;
local_n_btmask = cdata->local_n_btmask;
local_n_btshft = cdata->local_n_btshft;
local_n_tmask = cdata->local_n_tmask;
@@ -1086,6 +1019,7 @@ coff_symtab_read (symtab_offset, nsyms,
new->name =
process_coff_symbol (&fcn_cs_saved, &fcn_aux_saved,
section_offsets, objfile);
+ record_line (current_subfile, fcn_first_line, cs->c_value);
}
else if (STREQ (cs->c_name, ".ef"))
{
@@ -1458,7 +1392,7 @@ enter_linenos (file_offset, first_line,
rawptr += local_linesz;
/* The next function, or the sentinel, will have L_LNNO32 zero; we exit. */
if (L_LNNO32 (&lptr) && L_LNNO32 (&lptr) <= last_line)
- coff_record_line (first_line + L_LNNO32 (&lptr),
+ record_line (current_subfile, first_line + L_LNNO32 (&lptr),
lptr.l_addr.l_paddr
+ ANOFFSET (section_offsets, SECT_OFF_TEXT));
else
From shebs@cygnus.com Thu Apr 08 15:21:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: phdm@macqel.be
Cc: gdb-patches@cygnus.com, gdb@cygnus.com
Subject: Re: testsuite/print_long_arg_list
Date: Thu, 08 Apr 1999 15:21:00 -0000
Message-id: <199904082043.NAA29533@andros.cygnus.com>
References: <199904071649.SAA28333@mail.macqel.be>
X-SW-Source: 1999-04/msg00003.html
Content-length: 1035
Date: Wed, 7 Apr 1999 18:49:38 +0200 (CEST)
From: "Philippe De Muyter" <phdm@macqel.be>
Running the testsuite with gdb-4.17.87 on m68k-motorola-sysv, I got
(among others) the following failure :
print_long_arg_list (a=22.219999999999998, b=33.332999999999998, c=0, d=-25, e=1
[...]
Looking at the expected result, I see :
gdb_expect {
-re ".*print_long_arg_list \\(a=22.219999999999999, b=33.332999999999998
[...]
For me, the differences are in the last digits of some float or double numbers.
Isn't the test too strict ?
I'm no floating-point expert, but I do know that you're supposed to be
careful about ignoring the last digit. On the other hand, GDB just
uses a printf %g to display float values, so the output is going to
depend on the system's C library as much as GDB's correctness. In fact,
"a" is actually 22.22 in the sources, so even the expected test result
isn't what it should be.
My inclination is to relax the match here. What does everybody else
think?
Stan
From jtc@redback.com Thu Apr 08 15:52:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@cygnus.com
Cc: phdm@macqel.be, gdb@cygnus.com
Subject: Re: testsuite/print_long_arg_list
Date: Thu, 08 Apr 1999 15:52:00 -0000
Message-id: <5mg16aycjf.fsf@jtc.redbacknetworks.com>
References: <199904082043.NAA29533@andros.cygnus.com>
X-SW-Source: 1999-04/msg00004.html
Content-length: 845
>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I'm no floating-point expert, but I do know that you're supposed
Stan> to be careful about ignoring the last digit. On the other hand,
Stan> GDB just uses a printf %g to display float values, so the output
Stan> is going to depend on the system's C library as much as GDB's
Stan> correctness. In fact, "a" is actually 22.22 in the sources, so
Stan> even the expected test result isn't what it should be.
Stan> My inclination is to relax the match here. What does everybody
Stan> else think?
Isn't the problem that 22.22 cannot be represented exactly in binary
floating point, thus is subject to various rounding issues in the
least significant digits? Perhaps using values like 22.5, 22.25,
22.125, etc. would eliminate these problems.
--jtc
--
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Thu Apr 08 16:17:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@cygnus.com, phdm@macqel.be, gdb@cygnus.com
Subject: Re: testsuite/print_long_arg_list
Date: Thu, 08 Apr 1999 16:17:00 -0000
Message-id: <199904082301.QAA29767@andros.cygnus.com>
References: <5mg16aycjf.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-04/msg00005.html
Content-length: 537
From: jtc@redback.com (J.T. Conklin)
Date: 08 Apr 1999 15:26:12 -0700
Isn't the problem that 22.22 cannot be represented exactly in binary
floating point, thus is subject to various rounding issues in the
least significant digits? Perhaps using values like 22.5, 22.25,
22.125, etc. would eliminate these problems.
Doh! I should've thought of that! Yes, that does give better
results, and the author of those tests, who is on this list, says
"change 'em however you want". So that's what will happen. Thanks! -s
From assign@gnu.org Fri Apr 09 13:37:00 1999
From: assignments <assign@gnu.org>
To: gdb-patches@cygnus.com
Subject: gdb disclaims/assignments
Date: Fri, 09 Apr 1999 13:37:00 -0000
Message-id: <199904091948.PAA08091@delysid.gnu.org>
X-SW-Source: 1999-04/msg00006.html
Content-length: 966
The following disclaimers and/or assignments concerning GDB
have recently been added to the file copyright.list here at the
Free Software Foundation. If you have any questions or corrections,
please send them to my general work address, 3diff@gnu.org.
Thanks!
Brian Youmans
Assignments Clerk
GDB Kenneth G. Raeburn US 1966 1999-03-20
Assigns past and future changes.
raeburn@mit.edu
GDB Stephane Carrez France 1967 1999-02-25
Assigns past and future changes.
Stephane.Carrez@worldnet.fr
ANY BINUTILS GDB Sun Microsystems France 1998-11-23
Disclaims changes to free software by Stephane Carrez in the past
and for one year in the future.
GDB Kevin A. Buettner US 1961 1999-03-20
Assigns changes (list on assignment).
kev@primenet.com
GDB Metrowerks Corporation 1999-03-15
Disclaims changes by Kevin Buettner.
^ permalink raw reply [flat|nested] 4+ messages in thread