This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
RE: symtab/1877: gdb says that tthere is no information for a macro when readelf clearly identifies the macro
- From: "Vidyasagara Guntaka" <vguntaka at Brocade dot COM>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 28 Feb 2005 17:28:01 -0000
- Subject: RE: symtab/1877: gdb says that tthere is no information for a macro when readelf clearly identifies the macro
- Reply-to: "Vidyasagara Guntaka" <vguntaka at Brocade dot COM>
The following reply was made to PR symtab/1877; it has been noted by GNATS.
From: "Vidyasagara Guntaka" <vguntaka@Brocade.COM>
To: "Claus-Justus Heine" <ch@dot-heine.de>,
<gdb-gnats@sources.redhat.com>, <nobody@sources.redhat.com>,
<gdb-prs@sources.redhat.com>
Cc:
Subject: RE: symtab/1877: gdb says that tthere is no information for a macro when readelf clearly identifies the macro
Date: Mon, 28 Feb 2005 09:26:30 -0800
Dear Claus,
Thanks a lot for the quick response. I applied the path and it all just
worked fine.
What should be the course of next action? Should there be another issue
submitted to gcc's bug-tracking list as well to address the issue of not
generating ".file N NAME" for main source file?
Thanks and regards,
Sagar.
-----Original Message-----
From: Claus-Justus Heine [mailto:ch@dot-heine.de]=20
Sent: Sunday, February 27, 2005 8:08 AM
To: gdb-gnats@sources.redhat.com; nobody@sources.redhat.com; Vidyasagara
Guntaka; gdb-prs@sources.redhat.com
Subject: Re: symtab/1877: gdb says that tthere is no information for a
macro when readelf clearly identifies the macro
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=3Dview audit-trail
Hello together,
here is the reason and a bug-fix patch:
The problem is that gcc (as of gcc-3.4.3) does not emit a ".file N
FILENAME"
statement for the main compilation unit. Consider the following simple
example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
#include <stdio.h>
#define ADD(x) (M + x)
main ()
{
#define N 28
#define M 42
printf ("We're so creative: %d.\n", ADD(N));
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~
Now run
gcc -g3 -gdwarf-2 -o sample.s -S sample.c
You'll get the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
.file "sample.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.section .debug_macinfo,"",@progbits
.Ldebug_macinfo0:
.text
.Ltext0:
.section .debug_macinfo
.byte 0x1
.uleb128 0x1
.string "__STDC_HOSTED__ 1"
[BIG SNIP, lot's of other predefined symbols]
.string "__ELF__ 1"
.byte 0x3
.uleb128 0x1
----> .file 1 "/usr/include/stdio.h" <----
.uleb128 0x1
.byte 0x1
.uleb128 0x1b
.string "_STDIO_H 1"
.byte 0x3
.uleb128 0x1c
[SNIP, lot's of other stuff]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
The point is now that gdb's macro parsing code only looks at the ".file
N
NAME" statements to assign macro definitions to source files (or rather
their
equivalent after the assembler has converted the stuff to binary).
However,
there is no such note for the main compilation unit. The result is that
every
macro definition in the main source file is ignored:
(gdb) info macro ADD
The symbol `ADD' has no definition as a C/C++ preprocessor macro
at /var/tmp/sample.c:9
included at /usr/include/stdio.h:749
gdb even thinks that stdio.h has included sample.c (only w.r.t. macro
definitions).
FIX (patch included at end of file):
I don't know whether gdb is right or gcc, but gdb should be able to cope
with
gcc's output.
Proposal:
- When gdb encounters a DW_MACINFO_define or DW_MACINFO_undef mac-info
in
dwarf_decode_macros() but has not yet encountered a
DW_MACINFO_start_file
mac-info, then gdb should assume that the macro belongs to the main
source file. The
main source file's name is passed down to dwarf_decode_macros() from
read_file_scope() which has that information (at least in general).
Still the question arises: is this a work-around for a gcc bug, that is:
there
should be a DW_MACINFO_start_file mac-info for the main source file (aka
"compilation unit"), or is this a gdb bug? If it's a gcc bug then it
should be
reported to gcc's bug-tracking system.
Below the patch. It's also included as attachment in case there are
line-breaking issues=20
(sorry for the redundancy, but it is quite small)
Oh well, the patch is for gdb-6.3, apply with
cd gdb-6.3
patch -p0 < PATCH_FILE
Best regards
Claus
################################## snip
######################################
--- gdb/dwarf2read.c~ 2004-10-16 02:41:00.000000000 +0200
+++ gdb/dwarf2read.c 2005-02-27 16:23:30.464351640 +0100
@@ -1014,7 +1014,8 @@
static void add_to_cu_func_list (const char *, CORE_ADDR, CORE_ADDR,
struct dwarf2_cu *);
-static void dwarf_decode_macros (struct line_header *, unsigned int,
+static void dwarf_decode_macros (const char *cu_name,
+ struct line_header *, unsigned int,
char *, bfd *, struct dwarf2_cu *);
static int attr_form_is_block (struct attribute *);
@@ -2825,7 +2826,8 @@
if (attr && line_header)
{
unsigned int macro_offset =3D DW_UNSND (attr);
- dwarf_decode_macros (line_header, macro_offset,
+ dwarf_decode_macros (name /* comilation unit */,
+ line_header, macro_offset,
comp_dir, abfd, cu);
}
do_cleanups (back_to);
@@ -9010,7 +9012,8 @@
static void
-dwarf_decode_macros (struct line_header *lh, unsigned int offset,
+dwarf_decode_macros (const char *cu_name,
+ struct line_header *lh, unsigned int offset,
char *comp_dir, bfd *abfd,
struct dwarf2_cu *cu)
{
@@ -9061,19 +9064,29 @@
mac_ptr +=3D bytes_read;
if (! current_file)
- complaint (&symfile_complaints,
- "debug info gives macro %s outside of any file:
%s",
- macinfo_type =3D=3D
- DW_MACINFO_define ? "definition" : macinfo_type
=3D=3D
- DW_MACINFO_undef ? "undefinition" :
- "something-or-other", body);
- else
- {
- if (macinfo_type =3D=3D DW_MACINFO_define)
- parse_macro_definition (current_file, line, body);
- else if (macinfo_type =3D=3D DW_MACINFO_undef)
- macro_undef (current_file, line, body);
- }
+ {
+ complaint (&symfile_complaints,
+ "debug info gives macro %s outside of any
file: %s,"
+ " assuming main compilation unit",
+ macinfo_type =3D=3D
+ DW_MACINFO_define ? "definition" :
macinfo_type =3D=3D
+ DW_MACINFO_undef ? "undefinition" :
+ "something-or-other", body);
+ if (! pending_macros)
+ pending_macros =3D
+ new_macro_table (&cu->objfile->objfile_obstack,
+ cu->objfile->macro_cache);
+
+ /* If we have no current file, then this must be the
+ start_file directive for the compilation unit's
+ main source file. */
+ current_file =3D macro_set_main (pending_macros, cu_name);
+ }
+
+ if (macinfo_type =3D=3D DW_MACINFO_define)
+ parse_macro_definition (current_file, line, body);
+ else if (macinfo_type =3D=3D DW_MACINFO_undef)
+ macro_undef (current_file, line, body);
}
break;
############################## snap ##########################