From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Philippe De Muyter" To: gdb-patches@cygnus.com (gdb-patches@cygnus.com) Subject: coffread.c and one-line functions Date: Wed, 07 Apr 1999 21:50:00 -0000 Message-id: <199904080450.GAA31507@mail.macqel.be> X-SW-Source: 1999-q2/msg00002.html Thu Apr 8 06:26:12 1999 Philippe De Muyter * 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; } -/* 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; -} - /* 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; } @@ -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 mboxrd@z Thu Jan 1 00:00:00 1970 From: "Philippe De Muyter" To: gdb-patches@cygnus.com (gdb-patches@cygnus.com) Subject: coffread.c and one-line functions Date: Wed, 07 Apr 1999 22:49:00 -0000 Message-ID: <199904080450.GAA31507@mail.macqel.be> X-SW-Source: 1999-04/msg00002.html Message-ID: <19990407224900.iTPPvTszmb2eZB00xIyb-q-XURGj7vN6bDt9tf1rAkc@z> Thu Apr 8 06:26:12 1999 Philippe De Muyter * 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; } -/* 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; -} - /* 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; } @@ -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 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" 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 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 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 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.