[gcc commit] [gcc patch] DWARF-5: Define DW_IDX_GNU_static and DW_IDX_GNU_external
On Sun, 02 Jul 2017 18:22:45 +0200, Jason Merrill wrote: > I'd suggest "internal" rather than "static". Otherwise the patch looks good. Checked in as r249883 with: DW_IDX_GNU_internal, DW_IDX_GNU_external Jan
ping^2: [gcc patch] DWARF-5: Define DW_IDX_GNU_static and DW_IDX_GNU_external
http://dwarfstd.org/ShowIssue.php?issue=170527.1 170527.1 Jan Kratochvil DW_IDX_* for static/extern symbols Enhancement Open Section 6.1.1.4.7, pg 147 When a debugger wants to print 'somename' it logically tries to find first 'somename' as an external symbol in all available libraries. Only if none such external symbol is found the debugger starts searching for a static 'somename' symbol in those libraries. This requires to know whether a symbol in .debug_names index has DW_AT_external or not. Otherwise a lot of needless CU expansions happen. This extension improves performance gain of the .debug_names index. (Discovered in an original fix by Doug Evans - GDB Bug 14125.) Proposing and asking for pre-allocation: DW_IDX_static = 6 = DW_FORM_flag_present = DIE's DW_AT_external is not present DW_IDX_external = 7 = DW_FORM_flag_present = DIE's DW_AT_external is present
ping: [gcc patch] DWARF-5: Define DW_IDX_GNU_static and DW_IDX_GNU_external
http://dwarfstd.org/ShowIssue.php?issue=170527.1
170527.1 Jan Kratochvil DW_IDX_* for static/extern symbols Enhancement Open
Section 6.1.1.4.7, pg 147
When a debugger wants to print 'somename' it logically tries to find first
'somename' as an
external symbol in all available libraries. Only if none such external symbol
is found the
debugger starts searching for a static 'somename' symbol in those libraries.
This requires to know whether a symbol in .debug_names index has DW_AT_external
or not.
Otherwise a lot of needless CU expansions happen. This extension improves
performance
gain of the .debug_names index.
(Discovered in an original fix by Doug Evans - GDB Bug 14125.)
Proposing and asking for pre-allocation:
DW_IDX_static = 6 = DW_FORM_flag_present = DIE's DW_AT_external is not
present
DW_IDX_external = 7 = DW_FORM_flag_present = DIE's DW_AT_external is present
include/ChangeLog
2017-05-26 Jan Kratochvil <jan.kratoch...@redhat.com>
* dwarf2.def (DW_IDX_compile_unit, DW_IDX_type_unit, DW_IDX_die_offset)
(DW_IDX_parent, DW_IDX_type_hash, DW_IDX_lo_user, DW_IDX_hi_user)
(DW_IDX_GNU_static, DW_IDX_GNU_external): New.
* dwarf2.h (DW_IDX, DW_IDX_DUP, DW_FIRST_IDX, DW_END_IDX): New.
(enum dwarf_name_index_attribute): Remove.
(get_DW_IDX_name): New declaration.
libiberty/ChangeLog
2017-05-26 Jan Kratochvil <jan.kratoch...@redhat.com>
* dwarfnames.c (DW_FIRST_IDX, DW_END_IDX, DW_IDX, DW_IDX_DUP): New.
diff --git a/include/dwarf2.def b/include/dwarf2.def
index ea6194e..1f0d50f 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -782,3 +782,15 @@ DW_CFA (DW_CFA_GNU_args_size, 0x2e)
DW_CFA (DW_CFA_GNU_negative_offset_extended, 0x2f)
DW_END_CFA
+
+/* Index attributes in the Abbreviations Table. */
+DW_FIRST_IDX (DW_IDX_compile_unit, 1)
+DW_IDX (DW_IDX_type_unit, 2)
+DW_IDX (DW_IDX_die_offset, 3)
+DW_IDX (DW_IDX_parent, 4)
+DW_IDX (DW_IDX_type_hash, 5)
+DW_IDX_DUP (DW_IDX_lo_user, 0x2000)
+DW_IDX (DW_IDX_hi_user, 0x3fff)
+DW_IDX (DW_IDX_GNU_static, 0x2000)
+DW_IDX (DW_IDX_GNU_external, 0x2001)
+DW_END_IDX
diff --git a/include/dwarf2.h b/include/dwarf2.h
index 9c78880..14b6f22 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -52,6 +52,8 @@
#define DW_ATE(name, value) , name = value
#define DW_ATE_DUP(name, value) , name = value
#define DW_CFA(name, value) , name = value
+#define DW_IDX(name, value) , name = value
+#define DW_IDX_DUP(name, value) , name = value
#define DW_FIRST_TAG(name, value) enum dwarf_tag { \
name = value
@@ -71,6 +73,9 @@
#define DW_FIRST_CFA(name, value) enum dwarf_call_frame_info { \
name = value
#define DW_END_CFA };
+#define DW_FIRST_IDX(name, value) enum dwarf_name_index_attribute { \
+ name = value
+#define DW_END_IDX };
#include "dwarf2.def"
@@ -86,6 +91,8 @@
#undef DW_END_ATE
#undef DW_FIRST_CFA
#undef DW_END_CFA
+#undef DW_FIRST_IDX
+#undef DW_END_IDX
#undef DW_TAG
#undef DW_TAG_DUP
@@ -97,6 +104,8 @@
#undef DW_ATE
#undef DW_ATE_DUP
#undef DW_CFA
+#undef DW_IDX
+#undef DW_IDX_DUP
/* Flag that tells whether entry has a child or not. */
#define DW_children_no 0
@@ -420,18 +429,6 @@ enum dwarf_macro_record_type
DW_MACRO_GNU_hi_user = 0xff
};
-/* Index attributes in the Abbreviations Table. */
-enum dwarf_name_index_attribute
- {
-DW_IDX_compile_unit = 1,
-DW_IDX_type_unit = 2,
-DW_IDX_die_offset = 3,
-DW_IDX_parent = 4,
-DW_IDX_type_hash = 5,
-DW_IDX_lo_user = 0x2000,
-DW_IDX_hi_user = 0x3fff
- };
-
/* Range list entry kinds in .debug_rnglists* section. */
enum dwarf_range_list_entry
{
@@ -524,6 +521,10 @@ extern const char *get_DW_ATE_name (unsigned int enc);
recognized. */
extern const char *get_DW_CFA_name (unsigned int opc);
+/* Return the name of a DW_IDX_ constant, or NULL if the value is not
+ recognized. */
+extern const char *get_DW_IDX_name (unsigned int idx);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
diff --git a/libiberty/dwarfnames.c b/libiberty/dwarfnames.c
index 62563b7..e58d03c 100644
--- a/libiberty/dwarfnames.c
+++ b/libiberty/dwarfnames.c
@@ -59,6 +59,11 @@ Boston, MA 02110-1301, USA. */
switch (opc) { \
DW_CFA (name, value)
#define DW_END_CFA } return 0; }
+#define DW_FIRST_IDX(name, value) \
+ const char *get_DW_IDX_name (unsigned int idx) { \
+ switch (idx) { \
+ DW_IDX (name, value)
+#define DW_END_IDX } return 0; }
#define DW_TAG(name, value) case name: return # name ;
#define DW_TAG_DUP(name, value)
@@ -70,6 +75,8 @@ Boston, MA 02110-1301, USA. */
#define DW_ATE(name, value) case name: return # name ;
#define DW_ATE_DUP(name, value)
#define DW_CFA(name, value) case name: return # name ;
+#define DW_IDX(name, value) case name: return # name ;
+#define DW_IDX_DUP(name, value)
#include "dwarf2.def"
@@ -85,6 +92,8 @@ Boston,
Re: [gcc patch] DWARF-5: Define DW_IDX_GNU_static and DW_IDX_GNU_external
On Fri, 26 May 2017 20:14:08 +0200, Jan Kratochvil wrote: > If those new DW_IDX_* get allocated in a reasonable time GDB could already use > them, otherwise sending the patch below. Preallocation of the numbers has been denied by DWARF committee. Therefore asking for approval of this patch in its DW_IDX_GNU_* posted form. http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2017-June/004370.html Thanks, Jan
[gcc patch] DWARF-5: Define DW_IDX_GNU_static and DW_IDX_GNU_external
Hi,
I missed the DWARF-5 deadline so I have submitted this for DWARF-6
(not yet on http://dwarfstd.org ):
--
.gdb_index contained an attribute for each symbol whether it is DW_AT_external
or not.
/* Whether the symbol is in GLOBAL_BLOCK (== 0) or STATIC_BLOCK (== 1). */
#define GDB_INDEX_SYMBOL_STATIC_SHIFT 31
#define GDB_INDEX_SYMBOL_STATIC_MASK 1
The reason is:
Performance issue with .gdb_index and large numbers of shared libs
https://sourceware.org/bugzilla/show_bug.cgi?id=14125
When .gdb_index is in use there isn't a bit that specifies GLOBAL_BLOCK vs
STATIC_BLOCK, so if something is in STATIC_BLOCK (say "int") it matches so
gdb will expand the symbol table, but the match doesn't take into account
the block kind. So gdb will proceed to expand one symbol table from every
objfile looking for "int" in GLOBAL_BLOCK, finding it, but not using it.
Only after that is done will GDB try STATIC_BLOCK. In a large enough app
(e.g., >1000 shared libs) this is painful.
Proposing and asking for pre-allocation:
DW_IDX_static = 6 = DW_FORM_flag_present = DIE's DW_AT_external is not
present
DW_IDX_external = 7 = DW_FORM_flag_present = DIE's DW_AT_external is present
--
If those new DW_IDX_* get allocated in a reasonable time GDB could already use
them, otherwise sending the patch below.
These symbols are both produced and consumed only by GDB, not by GCC.
Jan
include/ChangeLog
2017-05-26 Jan Kratochvil <jan.kratoch...@redhat.com>
* dwarf2.def (DW_IDX_compile_unit, DW_IDX_type_unit, DW_IDX_die_offset)
(DW_IDX_parent, DW_IDX_type_hash, DW_IDX_lo_user, DW_IDX_hi_user)
(DW_IDX_GNU_static, DW_IDX_GNU_external): New.
* dwarf2.h (DW_IDX, DW_IDX_DUP, DW_FIRST_IDX, DW_END_IDX): New.
(enum dwarf_name_index_attribute): Remove.
(get_DW_IDX_name): New declaration.
libiberty/ChangeLog
2017-05-26 Jan Kratochvil <jan.kratoch...@redhat.com>
* dwarfnames.c (DW_FIRST_IDX, DW_END_IDX, DW_IDX, DW_IDX_DUP): New.
diff --git a/include/dwarf2.def b/include/dwarf2.def
index ea6194e..1f0d50f 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -782,3 +782,15 @@ DW_CFA (DW_CFA_GNU_args_size, 0x2e)
DW_CFA (DW_CFA_GNU_negative_offset_extended, 0x2f)
DW_END_CFA
+
+/* Index attributes in the Abbreviations Table. */
+DW_FIRST_IDX (DW_IDX_compile_unit, 1)
+DW_IDX (DW_IDX_type_unit, 2)
+DW_IDX (DW_IDX_die_offset, 3)
+DW_IDX (DW_IDX_parent, 4)
+DW_IDX (DW_IDX_type_hash, 5)
+DW_IDX_DUP (DW_IDX_lo_user, 0x2000)
+DW_IDX (DW_IDX_hi_user, 0x3fff)
+DW_IDX (DW_IDX_GNU_static, 0x2000)
+DW_IDX (DW_IDX_GNU_external, 0x2001)
+DW_END_IDX
diff --git a/include/dwarf2.h b/include/dwarf2.h
index 9c78880..14b6f22 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -52,6 +52,8 @@
#define DW_ATE(name, value) , name = value
#define DW_ATE_DUP(name, value) , name = value
#define DW_CFA(name, value) , name = value
+#define DW_IDX(name, value) , name = value
+#define DW_IDX_DUP(name, value) , name = value
#define DW_FIRST_TAG(name, value) enum dwarf_tag { \
name = value
@@ -71,6 +73,9 @@
#define DW_FIRST_CFA(name, value) enum dwarf_call_frame_info { \
name = value
#define DW_END_CFA };
+#define DW_FIRST_IDX(name, value) enum dwarf_name_index_attribute { \
+ name = value
+#define DW_END_IDX };
#include "dwarf2.def"
@@ -86,6 +91,8 @@
#undef DW_END_ATE
#undef DW_FIRST_CFA
#undef DW_END_CFA
+#undef DW_FIRST_IDX
+#undef DW_END_IDX
#undef DW_TAG
#undef DW_TAG_DUP
@@ -97,6 +104,8 @@
#undef DW_ATE
#undef DW_ATE_DUP
#undef DW_CFA
+#undef DW_IDX
+#undef DW_IDX_DUP
/* Flag that tells whether entry has a child or not. */
#define DW_children_no 0
@@ -420,18 +429,6 @@ enum dwarf_macro_record_type
DW_MACRO_GNU_hi_user = 0xff
};
-/* Index attributes in the Abbreviations Table. */
-enum dwarf_name_index_attribute
- {
-DW_IDX_compile_unit = 1,
-DW_IDX_type_unit = 2,
-DW_IDX_die_offset = 3,
-DW_IDX_parent = 4,
-DW_IDX_type_hash = 5,
-DW_IDX_lo_user = 0x2000,
-DW_IDX_hi_user = 0x3fff
- };
-
/* Range list entry kinds in .debug_rnglists* section. */
enum dwarf_range_list_entry
{
@@ -524,6 +521,10 @@ extern const char *get_DW_ATE_name (unsigned int enc);
recognized. */
extern const char *get_DW_CFA_name (unsigned int opc);
+/* Return the name of a DW_IDX_ constant, or NULL if the value is not
+ recognized. */
+extern const char *get_DW_IDX_name (unsigned int idx);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
diff --git a/libiberty/dwarfnames.c b/libiberty/dwarfnames.c
index 62563b7..e58d03c 100644
--- a/libiberty/dwarfnames.c
+++ b/libiberty/dwarfnames.c
@@ -59,6 +59,11 @@ Boston, MA 02110-1301, USA. */
switch (opc) { \
DW_CFA (name, value)
#define D
Re: [PATCH] Remove padding from DWARF5 headers
On Wed, 04 Jan 2017 00:09:43 +0100, Jakub Jelinek wrote: > Jan/Mark, are you going to adjust GDB/elfutils etc. correspondingly? My GDB DWARF-5 patchset is still off-trunk so that is sure OK. Jan
Re: [PATCH] PR59170 make pretty printers check for singular iterators
On Fri, 16 Dec 2016 14:17:32 +0100, Jonathan Wakely wrote:
> On 16/12/16 14:06 +0100, Jan Kratochvil wrote:
> > (gdb) p bb.c.d
> > $4 = (D &) @0x601028: {e = 0x601060 }
>
> Wat?
>
> bb.c.d is not a valid expression.
>
> B::c is a pointer, it should be bb.c->d
>
> Is it GDB policy to make invalid expressions like that "work"?
Yes, this is a GDB extension from the times of plain C. In C++ it became
a problem. That was not the topic of this example for the initial
dereferencing operator.
> I had no idea this even worked, I'd have used bb.c->d.e->i because
> that's the correct expression for accessing that variable.
There was a plan to make the 'compile' project backward compatible with these
confusing GDB universal dot operators.
Jan
Re: [PATCH] PR59170 make pretty printers check for singular iterators
On Fri, 16 Dec 2016 13:33:52 +0100, Jonathan Wakely wrote:
> We don't do auto-deref for std::shared_ptr or std::unique_ptr, even
> though we know the object they point to definitely is live and safe to
> access, and that's because those types have pointer semantics not
> reference semantics.
This is wrong std::shared_ptr or std::unique_ptr is not auto-dereferenced for
GDB printing. But it may be more a GDB problem, not libstdc++ pretty printers
problem.
For example glib pretty printers already auto-dereference data structures:
5 GList* list = NULL;
(gdb) p/r list
$1 = (GList *) 0x607a00
(gdb) p list
$2 = 0x607a00 = {0x400810}
/usr/share/glib-2.0/gdb/glib.py
if type.code == gdb.TYPE_CODE_PTR:
type = type.target().unqualified()
t = str(type)
if t == "GList":
return GListPrinter(val, "GList")
But that is more a GDB bug that should be solved even for generic pointers.
Currently while traversing through data structures one has to randomly add or
remove '*' from the beginning of the GDB print expression:
1 class E { int a[1000]; int i=42; } ee;
2 class D { E *e= } dd;
3 class C { D =dd; } cc;
4 class B { C *c= } bb;
5 int main() {}
(gdb) p bb
$1 = {c = 0x601030 }
(gdb) p bb.c
$2 = (C *) 0x601030
Oops, I need to add a dereference:
(gdb) p *bb.c
$3 = {d = @0x601028}
(gdb) p *bb.c.d
No symbol "operator*" in current context.
Oops, I need to remove a dereference:
(gdb) p bb.c.d
$4 = (D &) @0x601028: {e = 0x601060 }
(gdb) p bb.c.d.e
$5 = (E *) 0x601060
Oops, I need to add a dereference:
(gdb) p *bb.c.d.e
$6 = {a = {0 }, i = 42}
(gdb) p *bb.c.d.e.i
Cannot access memory at address 0x2a
Oops, I need to remove a dereference:
(gdb) p bb.c.d.e.i
$7 = 42
This is probably solved in some clickable front-end interfaces.
Jan
Re: [PATCH] PR59170 make pretty printers check for singular iterators
On Fri, 16 Dec 2016 02:07:07 +0100, Jonathan Wakely wrote: > On 15/12/16 22:19 +0100, Jan Kratochvil wrote: > > Just with the GDB 'compile' project (libcc1) which is planned to be used for > > all GDB expressions evalation the Xmethods will no longer work. > > But then *it can just get compiled, so it will still work, right? > > The only reason it doesn't work today is that the definition for > operator* might not be in the executable, but if you can compile a new > definition that doesn't matter. Currently it cannot as the source for gcc (via libcc1) is (re)generated from DWARF. Currently GDB does not provide original sources as a context for the compiled expression. Besides that there is a C++17 modules feature which should solve that for LLDB as pointed out by Pedro before: http://lists.llvm.org/pipermail/lldb-dev/2016-August/010870.html Unaware if/when GDB 'compile' will handle C++ modules as a sources substitute or if/when it will do the original source recompilation. Jan
Re: [PATCH] PR59170 make pretty printers check for singular iterators
On Thu, 15 Dec 2016 15:18:17 +0100, Jonathan Wakely wrote: > I'm going to add Xmethods for all our iterator types so that it will > always be possible to do "print *iter", so if GDB supports Xmethods > then we don't need to register the iterator printers. Just with the GDB 'compile' project (libcc1) which is planned to be used for all GDB expressions evalation the Xmethods will no longer work. Jan
[patch] DWARF5 .debug_line DW_LNCT_* reorder for readelf [Re: [PATCH] DWARF5 .debug_line{,_str} support]
Hi,
On Thu, 20 Oct 2016 01:30:39 +0200, Jakub Jelinek wrote:
> This patch adds support for DWARF5 .debug_line{,_str} section format,
> though only if !DWARF2_ASM_LINE_DEBUG_INFO, because otherwise
> .debug_line is emitted by the assembler.
with current GCC trunk (with the GCC patch above) binutils readelf DWARF-5
patch being prepared outputs:
The File name Table (offset 0x30):
Entry NameDir
0 (indirect line string, offset: 0x0): /home/jkratoch/t/classic.C 0
1 (indirect line string, offset: 0x11): classic.C 1
Please see the tabs there.
After this GCC patch below readelf would output:
The File name Table (offset 0x30):
Entry Dir Name
0 0 (indirect line string, offset: 0x0): /home/jkratoch/t/classic.C
1 1 (indirect line string, offset: 0x11): classic.C
That 'indirect line string' may get removed, that is irrelevant for this mail.
I could reorder that in readelf but I find it easier to do in GCC.
Also binutils has not switched to C++ yet so I have found the reordering not
trivial to do in readelf itself.
The readelf patch being prepared - not yet submitted:
https://people.redhat.com/jkratoch/readelf-dwarf5.patch
OK for GCC trunk?
Sorry I have not regression tested it, I would handle that before a check-in.
Thanks,
Jan
gcc/
2016-11-24 Jan Kratochvil <jan.kratoch...@redhat.com>
* dwarf2out.c (output_file_names) Reorder DW_LNCT_directory_index and
DW_LNCT_path.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 1dfff38..ff4318c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -11592,8 +11592,7 @@ output_file_names (void)
#else
dw2_asm_output_data (1, 2, "File name entry format count");
#endif
- dw2_asm_output_data_uleb128 (DW_LNCT_path, "DW_LNCT_path");
- dw2_asm_output_data_uleb128 (str_form, get_DW_FORM_name (str_form));
+ /* Keep DW_LNCT_path last for better binutils readelf readability. */
dw2_asm_output_data_uleb128 (DW_LNCT_directory_index,
"DW_LNCT_directory_index");
dw2_asm_output_data_uleb128 (idx_form, get_DW_FORM_name (idx_form));
@@ -11603,9 +11602,10 @@ output_file_names (void)
dw2_asm_output_data_uleb128 (DW_LNCT_size, "DW_LNCT_size");
dw2_asm_output_data_uleb128 (DW_FORM_udata, "DW_FORM_udata");
#endif
- dw2_asm_output_data_uleb128 (numfiles + 1, "File names count");
+ dw2_asm_output_data_uleb128 (DW_LNCT_path, "DW_LNCT_path");
+ dw2_asm_output_data_uleb128 (str_form, get_DW_FORM_name (str_form));
- output_line_string (str_form, filename0, "File Entry", 0);
+ dw2_asm_output_data_uleb128 (numfiles + 1, "File names count");
/* Include directory index. */
if (dwarf_version >= 5 && idx_form != DW_FORM_udata)
@@ -11618,6 +11618,8 @@ output_file_names (void)
dw2_asm_output_data_uleb128 (0, NULL);
dw2_asm_output_data_uleb128 (0, NULL);
#endif
+
+ output_line_string (str_form, filename0, "File Entry", 0);
}
/* Now write all the file names. */
@@ -11644,7 +11646,8 @@ output_file_names (void)
snprintf (filebuf, maxfilelen, "%s;%d",
files[file_idx].path + dirs[dir_idx].length, ver);
- output_line_string (str_form, filebuf, "File Entry", (unsigned) i + 1);
+ if (dwarf_version < 5)
+ output_line_string (str_form, filebuf, "File Entry", (unsigned) i + 1);
/* Include directory index. */
if (dwarf_version >= 5 && idx_form != DW_FORM_udata)
@@ -11662,10 +11665,14 @@ output_file_names (void)
dw2_asm_output_data_uleb128 ((vms_file_stats_name (files[file_idx].path,
0, , 0, 0) == 0)
? siz : 0, NULL);
+
+ if (dwarf_version >= 5)
+ output_line_string (str_form, filebuf, "File Entry", (unsigned) i + 1);
#else
- output_line_string (str_form,
- files[file_idx].path + dirs[dir_idx].length,
- "File Entry", (unsigned) i + 1);
+ if (dwarf_version < 5)
+ output_line_string (str_form,
+ files[file_idx].path + dirs[dir_idx].length,
+ "File Entry", (unsigned) i + 1);
/* Include directory index. */
if (dwarf_version >= 5 && idx_form != DW_FORM_udata)
@@ -11675,13 +11682,17 @@ output_file_names (void)
dw2_asm_output_data_uleb128 (dir_idx + idx_offset, NULL);
if (dwarf_version >= 5)
- continue;
-
- /* Modification time. */
- dw2_asm_output_data_uleb128 (0, NULL);
+ output_line_string (str_form,
+ files[file_idx].path + dirs[dir_idx].length,
+ "File Entry", (uns
Re: [PATCH] DWARF5 .debug_info headers, .debug_types -> .debug_info DW_UT_type
On Fri, 21 Oct 2016 21:32:42 +0200, Jakub Jelinek wrote:
> This patch changes the .debug_info headers to follow the current
> specification (I still hope the useless padding1/padding2 fields will be
> removed), and also changes the -gsplit-dwarf stuff to move dwo_id into
> the header and use DW_UT_{skeleton,split_*}.
During GDB consumer patch testing I needed this fix on top of your patch.
Jan
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 7c6a9e9..1c0ca35 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -2977,7 +2977,8 @@ skeleton_chain_node;
/* Fixed size portion of the DWARF compilation unit header. */
#define DWARF_COMPILE_UNIT_HEADER_SIZE \
- (DWARF_INITIAL_LENGTH_SIZE + DWARF_OFFSET_SIZE + 3)
+ (DWARF_INITIAL_LENGTH_SIZE + DWARF_OFFSET_SIZE \
+ + (dwarf_version < 5 ? 3 : 4 + 8 + DWARF_OFFSET_SIZE))
/* Fixed size portion of the DWARF comdat type unit header. */
#define DWARF_COMDAT_TYPE_UNIT_HEADER_SIZE \
Re: [patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448)
On Thu, 19 Nov 2015 21:21:51 +0100, Jan Kratochvil wrote: > * python/hook.in: Call register_libstdcxx_printers. > * python/libstdcxx/v6/__init__.py: Wrap it to > register_libstdcxx_printers. [...] > -import libstdcxx.v6 > +# Call a function as a plain import would not execute body of the included > file > +# on repeated reloads of this object file. > +from libstdcxx.v6 import register_libstdcxx_printers > +register_libstdcxx_printers(gdb.current_objfile()) Jonathan Wakely mentioned: [libstdc++] Refactor python/hook.in https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02518.html From: Siva Chandra <sivachan...@google.com> Message-ID: <cagyq6gyqmpzyjmn6326qtazstaac1azodk5jx3ztmofym5p...@mail.gmail.com> https://gcc.gnu.org/r215726 That change introduced this regression. This patch does not undo it, goal of the patch by Siva Chandra - minimizing hook.in - stays achieved. Jan
[commit] [patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448)
On Fri, 20 Nov 2015 18:40:46 +0100, Jonathan Wakely wrote: > The patch is OK for trunk and gcc-5-branch. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448 trunk: https://gcc.gnu.org/viewcvs/gcc?view=revision=230669 5.x: https://gcc.gnu.org/viewcvs/gcc?view=revision=230670 Jan
[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448)
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
https://bugzilla.redhat.com/show_bug.cgi?id=1279406
echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'
Actual:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = {> = {_M_impl =
{ = {<__gnu_cxx::new_allocator> = {},
}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}},
}
Expected:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = std::vector of length 0, capacity 0
Thanks,
Jan
* python/hook.in: Call register_libstdcxx_printers.
* python/libstdcxx/v6/__init__.py: Wrap it to
register_libstdcxx_printers.
diff --git a/libstdc++-v3/python/hook.in b/libstdc++-v3/python/hook.in
index 07fe4c6..703b6a7 100644
--- a/libstdc++-v3/python/hook.in
+++ b/libstdc++-v3/python/hook.in
@@ -55,4 +55,7 @@ if gdb.current_objfile () is not None:
if not dir_ in sys.path:
sys.path.insert(0, dir_)
-import libstdcxx.v6
+# Call a function as a plain import would not execute body of the included file
+# on repeated reloads of this object file.
+from libstdcxx.v6 import register_libstdcxx_printers
+register_libstdcxx_printers(gdb.current_objfile())
diff --git a/libstdc++-v3/python/libstdcxx/v6/__init__.py
b/libstdc++-v3/python/libstdcxx/v6/__init__.py
index de3aa72..d8e060c 100644
--- a/libstdc++-v3/python/libstdcxx/v6/__init__.py
+++ b/libstdc++-v3/python/libstdcxx/v6/__init__.py
@@ -15,10 +15,6 @@
import gdb
-# Load the pretty-printers.
-from .printers import register_libstdcxx_printers
-register_libstdcxx_printers(gdb.current_objfile())
-
# Load the xmethods if GDB supports them.
def gdb_has_xmethods():
try:
@@ -27,6 +23,11 @@ def gdb_has_xmethods():
except ImportError:
return False
-if gdb_has_xmethods():
-from .xmethods import register_libstdcxx_xmethods
-register_libstdcxx_xmethods(gdb.current_objfile())
+def register_libstdcxx_printers(obj):
+# Load the pretty-printers.
+from .printers import register_libstdcxx_printers
+register_libstdcxx_printers(obj)
+
+if gdb_has_xmethods():
+from .xmethods import register_libstdcxx_xmethods
+register_libstdcxx_xmethods(obj)
ping: [PATCH v3 1/4] libcc1: Introduce GCC_FE_VERSION_1
Hi, I was asked now about this [PATCH v3 1..4] series for a possible inclusion of its GDB patches counterpart into gdb-7.10. Jan
[commit#2] [patch#2] PR other/65366: Fix gdbhooks.py for GDB with Python3
On Mon, 08 Jun 2015 09:46:59 +0200, Richard Biener wrote: adding a import sys makes it work fine though. I do not see the sys error with either FSF GDB HEAD or Fedora 22 GDB. I agree it probably should be there. Thus, ok with also adding a imoprt sys. Done and checked in: r224223 Jan
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Thu, 04 Jun 2015 16:00:18 +0200, Jeff Law wrote: But my assertion is that stuff like what you've shown above simply isn't important to handle. What we need to look at are the common cases and I haven't seen a strong argument that the common cases can't be handled by gdb. If we target only 99% of cases then sure GDB-side is enough. Still the GDB side will be more code and IMHO at an inappropriate place. I was tought + expect that in GNU world it does not matter where a feature is implemented, it is more important to be implemented at the right place. All the reasons have been already exchanged and I read between lines GCC still does not want to accept this feature so I will reimplement it in GDB only. Jan
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote: On 3 June 2015 at 22:58, Jan Kratochvil jan.kratoch...@redhat.com wrote: In general parsing LHS vs. RHS is not so trivial: *array1@10 expression wrapped into - (*array2+a@c[1]+'@'+'\''@(*array1@10)[5])[2] Is this a real case? I cannot understand what this means, but it could simply be that I'm only familiar with the most basic uses of @ together with 'print'. I made a mistake there but unimportant one, let's say the expression is: a@c[1]+'@'+'\''+(*array2@(*array1@10)[5])[2] I do not find splitting this expression to LHS@RHS in GDB to be easy. These two expressions are equivalent for all operations except of sizeof(): pointer (*pointer@ANYTHING) So the expression a@c[1]+'@'+'\''+(*array2@(*array1@10)[5])[2] is equivalent to: a@c[1]+'@'+'\''+(*array2@ array1[5])[2] is equivalent to: a@c[1]+'@'+'\''+ array2 [2] There can be a GDB function which takes X and Y and evaluates: a@c[1]+'@'+'\''+(*X @ Y [5])[2] There can be a GDB function which takes X and Y and evaluates: (*X @Y ) With these constructs I want to say that it is not easy to make the LHS@RHS split in GDB without limiting valid expressions it can accept. Jan
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Thu, 04 Jun 2015 10:36:46 +0200, Manuel López-Ibáñez wrote: except for printing a memory region, and for that purpose one only needs to parse LHS@RHS and only one @ makes sense within the same print command. Yes, just LHS or RHS can be pretty complicated containing the '@' character at least in strings / character constants. I agree that GDB-side parser will work in almost all cases, just one can then always find some awkward countercase. Jan
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Thu, 04 Jun 2015 10:55:59 +0200, Jakub Jelinek wrote:
(gdb) p *(int (*)[4])a[0]
$1 = {1, 2, 3, 4}
(gdb) p *(char (*)[4])b[1]
$2 = bcde
Though, admittedly that is more typing than a[0]@4 or b[1]@4 .
I forgot during this discussion about the C style cast, you are right.
For some GDB functions needing to print arrays, one can use:
*POINTER@LENGTH
-
*(typeof(*(POINTER))(*)[LENGTH])POINTER
So that one can even extract type of the expression POINTER.
So that @ operator is only for user convenience and I agree it can be
implemented by LHS@RHS splitting on GDB side and some unsupported corner cases
do not matter much.
Jan
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Wed, 03 Jun 2015 16:55:24 +0200, Jeff Law wrote:
On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
So I guess at some level it's not clear to me why we need to support the @
operator in libcc1. So perhaps starting with a justification for
wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression can be for example
(*vararray@(3+1))
Parentheses still could be parsed by GDB, though.
Is your assertion here that you want to be able to handle more complex
operands on the LHS/RHS of the @ and that adding a general expression parser
to GDB for that would be painful/wasteful?
Yes.
But a statement expression could not be parsed by GDB:
compile print ({ __auto_type ptr=vararray+1; *ptr@3; })
But how important is this kind of usage?
Currently it is not because it does not work as I wrote.
Otherwise I think it could have some (marginal) use so that some custom
printing command can accept arbitrary expression and executing such ({...})
code with the given expression.
But nothing too important.
I have found now GDB can do also
*vararray@somevar
Yea. I've used this occasionally, but...
[...]
Accepting the syntax where the RHS doesn't fold down to a constant is easy.
OK, I would extend the patch for non-constant RHS, in the case this patch
would be approved in general.
99% of the time I've used a constant with the @ syntax in gdb. Doesn't this
conflict with the goal of supporting an arbitrary C expression on the
LHS/RHS of the @? If most uses for the RHS are just constants, then why do
we need the enhancement?
In general parsing LHS vs. RHS is not so trivial:
*array1@10
expression wrapped into -
(*array2+a@c[1]+'@'+'\''@(*array1@10)[5])[2]
My worry is that without the copy_node we're changing things inside op0.
ISTM that we should be generating a new node (ie, a new VAR_DECL) using the
type returned by build_array_type_nelts as its type.
OK, thanks for the advice. I would update the patch in the case this patch
would be approved in general.
On Wed, 03 Jun 2015 20:10:23 +0200, Manuel López-Ibáñez wrote:
It should be possible to arrange the inferior code in such a way that GCC
parses each side of @ independently
As I illustrate above I do not find it completely trivial and personally
I find more clean the patch to GCC than such a parsing in GDB. In the end the
GCC patch is very short.
But sure everything is possible. While for most of use cases it is probably
enough to just strrchr(expression,'@'), still compared to current c-exp.y
parsing it would mean for 'compile code' a regression for the remaining few
possible use cases. So it means to parse strings, backslashes, parentheses.
Parsing correctly arbitrary programs that may contain @ at arbitrary places
seems a can full of gigantic were-worms.
Currently GCC parses '@' only for objc and I think it is OK for GCC/GDB to
make array@size syntax unsupported for objc. So I do not see gigantic
were-worms anywhere myself.
Jan
[patch#2] PR other/65366: Fix gdbhooks.py for GDB with Python3
On Wed, 03 Jun 2015 10:25:20 +0200, Richard Biener wrote:
gdb 7.9, python 2.7.6
attaching a fix; I do not know much Python so check it, please.
OK for check-in?
I have found it reproducible by :
gdb -ex 'source /home/jkratoch/redhat/gcchead/gcc/gdbhooks.py' -ex 'b
*0xec25b0' -ex r -ex 'set python print-stack full' -ex 'p *(stmt_vec_info)$r12'
--args /home/jkratoch/redhat/gcchead-build/gcc/cc1plus ~/t/sigtest.C -o
/dev/null -Wall -g -O3
0xec25b0=
Breakpoint 1, free_stmt_vec_info (stmt=gimple_debug 0x71635b80) at
/home/jkratoch/redhat/gcchead/gcc/tree-vect-stmts.c:7754
7754 free (stmt_info);
Jan
gcc/
2015-06-03 Jan Kratochvil jan.kratoch...@redhat.com
PR other/65366
* gdbhooks.py (intptr): New function. Replace int(...) by intptr(...).
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index 20842bb..fe83376 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -149,6 +149,12 @@ tree_code_class_dict =
gdb.types.make_enum_dict(gdb.lookup_type('enum tree_code_
tcc_type = tree_code_class_dict['tcc_type']
tcc_declaration = tree_code_class_dict['tcc_declaration']
+# Python3 has int() with arbitrary precision (bignum). Python2 int() is 32-bit
+# on 32-bit hosts but remote targets may have 64-bit pointers there; Python2
+# long() is always 64-bit but Python3 no longer has anything named long.
+def intptr(gdbval):
+return long(gdbval) if sys.version_info.major == 2 else int(gdbval)
+
class Tree:
Wrapper around a gdb.Value for a tree, with various methods
@@ -158,7 +164,7 @@ class Tree:
self.gdbval = gdbval
def is_nonnull(self):
-return int(self.gdbval)
+return intptr(self.gdbval)
def TREE_CODE(self):
@@ -197,7 +203,7 @@ class TreePrinter:
# like gcc/print-tree.c:print_node_brief
# #define TREE_CODE(NODE) ((enum tree_code) (NODE)-base.code)
# tree_code_name[(int) TREE_CODE (node)])
-if int(self.gdbval) == 0:
+if intptr(self.gdbval) == 0:
return 'tree 0x0'
val_TREE_CODE = self.node.TREE_CODE()
@@ -209,17 +215,17 @@ class TreePrinter:
val_tclass = val_tree_code_type[val_TREE_CODE]
val_tree_code_name = gdb.parse_and_eval('tree_code_name')
-val_code_name = val_tree_code_name[int(val_TREE_CODE)]
+val_code_name = val_tree_code_name[intptr(val_TREE_CODE)]
#print(val_code_name.string())
-result = '%s 0x%x' % (val_code_name.string(), int(self.gdbval))
-if int(val_tclass) == tcc_declaration:
+result = '%s 0x%x' % (val_code_name.string(), intptr(self.gdbval))
+if intptr(val_tclass) == tcc_declaration:
tree_DECL_NAME = self.node.DECL_NAME()
if tree_DECL_NAME.is_nonnull():
result += ' %s' % tree_DECL_NAME.IDENTIFIER_POINTER()
else:
pass # TODO: labels etc
-elif int(val_tclass) == tcc_type:
+elif intptr(val_tclass) == tcc_type:
tree_TYPE_NAME = Tree(self.gdbval['type_common']['name'])
if tree_TYPE_NAME.is_nonnull():
if tree_TYPE_NAME.TREE_CODE() == IDENTIFIER_NODE:
@@ -242,8 +248,8 @@ class CGraphNodePrinter:
self.gdbval = gdbval
def to_string (self):
-result = 'cgraph_node* 0x%x' % int(self.gdbval)
-if int(self.gdbval):
+result = 'cgraph_node* 0x%x' % intptr(self.gdbval)
+if intptr(self.gdbval):
# symtab_node::name calls lang_hooks.decl_printable_name
# default implementation (lhd_decl_printable_name) is:
#return IDENTIFIER_POINTER (DECL_NAME (decl));
@@ -261,12 +267,12 @@ class DWDieRefPrinter:
self.gdbval = gdbval
def to_string (self):
-if int(self.gdbval) == 0:
+if intptr(self.gdbval) == 0:
return 'dw_die_ref 0x0'
-result = 'dw_die_ref 0x%x' % int(self.gdbval)
+result = 'dw_die_ref 0x%x' % intptr(self.gdbval)
result += ' %s' % self.gdbval['die_tag']
-if int(self.gdbval['die_parent']) != 0:
-result += ' parent=0x%x %s' % (int(self.gdbval['die_parent']),
+if intptr(self.gdbval['die_parent']) != 0:
+result += ' parent=0x%x %s' % (intptr(self.gdbval['die_parent']),
self.gdbval['die_parent']['die_tag'])
result += ''
@@ -279,13 +285,13 @@ class GimplePrinter:
self.gdbval = gdbval
def to_string (self):
-if int(self.gdbval) == 0:
+if intptr(self.gdbval) == 0:
return 'gimple 0x0'
val_gimple_code = self.gdbval['code']
val_gimple_code_name = gdb.parse_and_eval('gimple_code_name')
-val_code_name = val_gimple_code_name[int(val_gimple_code)]
+val_code_name = val_gimple_code_name[intptr(val_gimple_code)]
result = '%s 0x%x' % (val_code_name.string
[commit] [patch] PR other/65366: Fix gdbhooks.py for GDB with Python3
On Mon, 01 Jun 2015 22:59:03 +0200, Jason Merrill wrote: OK, thanks. Checked in: r224012 Jan
[gcc patchv2] libcc1: '@' GDB array operator
---BeginMessage---
gcc/c-family/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* c-common.c (c_fully_fold_internal, binary_op_error): Add ATSIGN_EXPR.
* c-lex.c (c_lex_with_flags): Add ATSIGN_EXPR.
gcc/c/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* c-parser.c (enum c_parser_prec): Add PREC_ATSIGN.
(c_parser_binary_expression): Add CPP_ATSIGN.
* c-typeck.c (build_binary_op): Add ATSIGN_EXPR.
gcc/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* tree-pretty-print.c (dump_generic_node, op_symbol_code): Add
ATSIGN_EXPR.
* tree.def: Add ATSIGN_EXPR.
---
gcc/c-family/c-common.c | 21 +
gcc/c-family/c-lex.c| 5 -
gcc/c/c-parser.c| 11 +++
gcc/c/c-typeck.c| 13 +
gcc/tree-pretty-print.c | 4
gcc/tree.def| 3 +++
6 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 36c984c..5d4f20f 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -1299,6 +1299,25 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
ret = fold (ret);
goto out;
+case ATSIGN_EXPR:
+ op0 = TREE_OPERAND (expr, 0);
+ op1 = TREE_OPERAND (expr, 1);
+ op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
+ maybe_const_itself, for_int_const);
+ STRIP_TYPE_NOPS (op0);
+ op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
+ maybe_const_itself, for_int_const);
+ STRIP_TYPE_NOPS (op1);
+ op1 = decl_constant_value_for_optimization (op1);
+ ret = op0;
+ TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0),
+ tree_to_uhwi (op1));
+ TREE_READONLY (ret) = TREE_READONLY (expr);
+ TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
+ TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
+ ret = fold (ret);
+ goto out;
+
case COMPOUND_EXPR:
case MODIFY_EXPR:
case PREDECREMENT_EXPR:
@@ -4287,6 +4306,8 @@ binary_op_error (location_t location, enum tree_code code,
opname = ||; break;
case BIT_XOR_EXPR:
opname = ^; break;
+case ATSIGN_EXPR:
+ opname = @; break;
default:
gcc_unreachable ();
}
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 85775014..a918fae 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -515,7 +515,10 @@ c_lex_with_flags (tree *value, location_t *loc, unsigned
char *cpp_flags,
break;
}
- /* FALLTHROUGH */
+ /* Create ATSIGN_EXPR for GDB. */
+ *value = NULL_TREE;
+ break;
+
case CPP_HASH:
case CPP_PASTE:
{
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 965b4b9..08219b9 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1173,6 +1173,7 @@ enum c_parser_prec {
PREC_EQ,
PREC_REL,
PREC_SHIFT,
+ PREC_ATSIGN,
PREC_ADD,
PREC_MULT,
NUM_PRECS
@@ -6329,6 +6330,16 @@ c_parser_binary_expression (c_parser *parser, struct
c_expr *after,
oprec = PREC_ADD;
ocode = MINUS_EXPR;
break;
+ case CPP_ATSIGN:
+ if (!c_binding_oracle)
+ {
+ error_at (c_parser_peek_token (parser)-location,
+ stray %qs in program, @);
+ goto out;
+ }
+ oprec = PREC_ATSIGN;
+ ocode = ATSIGN_EXPR;
+ break;
case CPP_LSHIFT:
oprec = PREC_SHIFT;
ocode = LSHIFT_EXPR;
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index f55d4c6..8d28993 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10977,6 +10977,19 @@ build_binary_op (location_t location, enum tree_code
code,
maybe_warn_bool_compare (location, code, orig_op0, orig_op1);
break;
+case ATSIGN_EXPR:
+ if (TREE_CODE (orig_op1) == INTEGER_CST)
+ {
+ result_type = build_array_type_nelts (type0, tree_to_uhwi (orig_op1));
+ converted = 1;
+ break;
+ }
+ /* Otherwise it would look unclear:
+error: invalid operands to binary @ (have âintâ and âintâ) */
+ error_at (location,
+ second parameter of operator %@% requires constant integer);
+ return error_mark_node;
+
default:
gcc_unreachable ();
}
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index cf875c8..59391eb 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -2037,6 +2037,7 @@ dump_generic_node (pretty_printer *pp, tree node, int
spc, int flags,
case LTGT_EXPR:
case ORDERED_EXPR:
case UNORDERED_EXPR:
+case ATSIGN_EXPR:
{
const char *op = op_symbol (node);
op0 = TREE_OPERAND (node, 0);
@@ -3432,6 +3433,9 @@ op_symbol_code (enum tree_code code
Re: ping: [gcc patch] libcc1: '@' GDB array operator
On Sat, 30 May 2015 07:42:35 +0200, Jeff Law wrote:
We're still digging out a
bit from the patches queued while preparing for the gcc5 release.
gcc6
So I guess at some level it's not clear to me why we need to support the @
operator in libcc1. So perhaps starting with a justification for
wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression can be for example
(*vararray@(3+1))
Parentheses still could be parsed by GDB, though.
But a statement expression could not be parsed by GDB:
compile print ({ __auto_type ptr=vararray+1; *ptr@3; })
But I have found now it does not work - it prints just a pointer, not an array
- due to:
1 int main (void) { typeof (({ int a[]={1,2,3,4,5}; a; })) *ptr_type;
return 0; }
(gdb) ptype ptr_type
type = int **
It is in DWARF really just:
DW_TAG_pointer_type - DW_TAG_pointer_type - DW_TAG_base_type
With future C++ support it also would not work:
1 int array[]={1,2,3,4,5};
2 auto copy(array);
(gdb) ptype copy
type = int *
I have found now GDB can do also
*vararray@somevar
while this GCC patch cannot:
gdb command line:1:39: error: second parameter of operator '@' requires
constant integer
I did not realize that myself before. I do not think there is an easy fix for
the GCC patch, is it? But I do not think it matters too much, IMO GDB users
usually put there just constant numbers, at least I do.
So all the currently working cases can be implemented also just in GDB.
I still find more correct to do it in GCC than to implement new kind of
expression parsing in GDB - which the 'compile' project tries to avoid.
But sure up to you whether it fits in GCC or not.
As for the patch itself, you noted you weren't sure if copy_node was right,
it would help if you'd describe what problem you were having that's solved
by copying the node. I wonder if you should be building up a node from
scratch here.
I have removed it and it works. But there are many statements I do not
understand and I only guess they should be copying similar code around.
The block of code can be replaced just by:
case ATSIGN_EXPR:
op0 = TREE_OPERAND (expr, 0);
op1 = TREE_OPERAND (expr, 1);
ret = op0;
TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0),
tree_to_uhwi (op1));
TREE_READONLY (ret) = TREE_READONLY (expr);
TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
goto out;
which also works for me. But I guess one could find some countercases for this
simplified block.
In general, please use C style comments rather than C++.
Done.
Jan
[PATCH v3 2/4] libcc1: set debug compile: Display GCC driver filename
Hi,
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not
display which one. It cannot, GCC method set_arguments() does not yet know
whether 'set debug compile' is enabled or not.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Rename compile to compile_v0. Update comment
for compile. New methods set_verbose and compile.
libcc1/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc: Include intl.h.
(struct libcc1): Add field verbose.
(libcc1::libcc1): Initialize it.
(libcc1_set_verbose): New function.
(libcc1_set_arguments): Print messages for VERBOSE.
(libcc1_compile): Remove parameter verbose. Use VERBOSE from SELF.
(libcc1_compile_v0): New function.
(vtable): Use libcc1_compile_v0 and add libcc1_compile and
libcc1_set_verbose.
---
include/gcc-interface.h | 33 ++---
libcc1/libcc1.cc| 38 +-
2 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index dcfa6ce..0b409d0 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -45,6 +45,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
+
+ /* Deprecated method compile_v0. Added method set_verbose and compile. */
GCC_FE_VERSION_1 = 1,
};
@@ -94,18 +96,35 @@ struct gcc_base_vtable
const char *message),
void *datum);
- /* Perform the compilation. FILENAME is the name of the resulting
- object file. VERBOSE can be set to cause GCC to print some
- information as it works. Returns true on success, false on
- error. */
+ /* Deprecated GCC_FE_VERSION_0 variant of the GCC_FE_VERSION_1
+ compile method. GCC_FE_VERSION_0 version verbose parameter has
+ been replaced by the set_verbose method. */
- int /* bool */ (*compile) (struct gcc_base_context *self,
-const char *filename,
-int /* bool */ verbose);
+ int /* bool */ (*compile_v0) (struct gcc_base_context *self,
+ const char *filename,
+ int /* bool */ verbose);
/* Destroy this object. */
void (*destroy) (struct gcc_base_context *self);
+
+ /* VERBOSE can be set to non-zero to cause GCC to print some
+ information as it works. Calling this method overrides its
+ possible previous calls.
+
+ This method is only available since GCC_FE_VERSION_1. */
+
+ void (*set_verbose) (struct gcc_base_context *self,
+ int /* bool */ verbose);
+
+ /* Perform the compilation. FILENAME is the name of the resulting
+ object file. Either set_triplet_regexp or set_driver_filename must
+ be called before. Returns true on success, false on error.
+
+ This method is only available since GCC_FE_VERSION_1. */
+
+ int /* bool */ (*compile) (struct gcc_base_context *self,
+const char *filename);
};
/* The GCC object. */
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index 99a0fa1..6fda5b9 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3. If not see
#include xregex.h
#include findcomp.hh
#include compiler-name.h
+#include intl.h
struct libcc1;
@@ -66,6 +67,9 @@ struct libcc1 : public gcc_c_context
std::vectorstd::string args;
std::string source_file;
+
+ /* Non-zero as an equivalent to gcc driver option -v. */
+ bool verbose;
};
// A local subclass of connection that holds a back-pointer to the
@@ -97,7 +101,8 @@ libcc1::libcc1 (const gcc_base_vtable *v,
print_function (NULL),
print_datum (NULL),
args (),
-source_file ()
+source_file (),
+verbose (false)
{
base.ops = v;
c_ops = cv;
@@ -306,6 +311,14 @@ make_regexp (const char *triplet_regexp, const char
*compiler)
return buf.str ();
}
+static void
+libcc1_set_verbose (struct gcc_base_context *s, int /* bool */ verbose)
+{
+ libcc1 *self = (libcc1 *) s;
+
+ self-verbose = verbose != 0;
+}
+
static char *
libcc1_set_arguments (struct gcc_base_context *s,
const char *triplet_regexp,
@@ -316,6 +329,10 @@ libcc1_set_arguments (struct gcc_base_context *s,
int code;
std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
+ // Simulate fnotice by fprintf.
+ if (self-verbose)
+fprintf (stderr, _(searching for compiler matching regex %s\n),
+rx.c_str());
code = regcomp (triplet, rx.c_str (), REG_EXTENDED | REG_NOSUB);
if (code != 0)
{
@@ -341,6 +358,8 @@ libcc1_set_arguments (struct gcc_base_context *s
[PATCH v3 1/4] libcc1: Introduce GCC_FE_VERSION_1
Hi,
the libcc1 API change formerly approved for GCC was rejected by GDB, therefore
here is a new API + its implementation.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add GCC_FE_VERSION_1.
libcc1/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc (vtable): Update to GCC_FE_VERSION_1.
(gcc_c_fe_context): Accept also GCC_FE_VERSION_1.
---
include/gcc-interface.h |3 ++-
libcc1/libcc1.cc|5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index 34010f2..dcfa6ce 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -44,7 +44,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
- GCC_FE_VERSION_0 = 0
+ GCC_FE_VERSION_0 = 0,
+ GCC_FE_VERSION_1 = 1,
};
/* The operations defined by the GCC base API. This is the vtable for
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index 7d7d2c1..99a0fa1 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -504,7 +504,7 @@ libcc1_destroy (struct gcc_base_context *s)
static const struct gcc_base_vtable vtable =
{
- GCC_FE_VERSION_0,
+ GCC_FE_VERSION_1,
libcc1_set_arguments,
libcc1_set_source_file,
libcc1_set_print_callback,
@@ -523,7 +523,8 @@ struct gcc_c_context *
gcc_c_fe_context (enum gcc_base_api_version base_version,
enum gcc_c_api_version c_version)
{
- if (base_version != GCC_FE_VERSION_0 || c_version != GCC_C_FE_VERSION_0)
+ if ((base_version != GCC_FE_VERSION_0 base_version != GCC_FE_VERSION_1)
+ || c_version != GCC_C_FE_VERSION_0)
return NULL;
return new libcc1 (vtable, c_vtable);
[PATCH v3 3/4] libcc1: Add 'set compile-gcc'
Hi,
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new option 'set compile-gcc'.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Update comment for
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Rename set_arguments to set_arguments_v0.
Add set_arguments, set_triplet_regexp and set_driver_filename.
libcc1/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc (libcc1): Add class compiler with field compilerp, class
compiler_triplet_regexp and class compiler_driver_filename.
(libcc1::libcc1): Initialize compilerp.
(libcc1::~libcc1): Delete compilerp.
(libcc1::compiler::find, libcc1::compiler_triplet_regexp::find)
(libcc1::compiler_driver_filename::find): New methods.
(libcc1_set_arguments): Remove parameter triplet_regexp.
(libcc1_set_triplet_regexp, libcc1_set_driver_filename)
(libcc1_set_arguments_v0): New functions.
(vtable): Use libcc1_set_arguments_v0, add libcc1_set_arguments,
libcc1_set_triplet_regexp and libcc1_set_driver_filename.
---
include/gcc-interface.h | 61 -
libcc1/libcc1.cc| 139 ++-
2 files changed, 172 insertions(+), 28 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index 0b409d0..1c66c3b 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -46,7 +46,9 @@ enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
- /* Deprecated method compile_v0. Added method set_verbose and compile. */
+ /* Deprecated methods set_arguments_v0 and compile_v0. Added methods
+ set_arguments, set_triplet_regexp, set_driver_filename, set_verbose and
+ compile. */
GCC_FE_VERSION_1 = 1,
};
@@ -67,20 +69,12 @@ struct gcc_base_vtable
unsigned int version;
- /* Set the compiler's command-line options for the next compilation.
- TRIPLET_REGEXP is a regular expression that is used to match the
- configury triplet prefix to the compiler.
- The arguments are copied by GCC. ARGV need not be
- NULL-terminated. The arguments must be set separately for each
- compilation; that is, after a compile is requested, the
- previously-set arguments cannot be reused.
-
- This returns NULL on success. On failure, returns a malloc()d
- error message. The caller is responsible for freeing it. */
+ /* Deprecated GCC_FE_VERSION_0 variant of the GCC_FE_VERSION_1
+ methods set_triplet_regexp and set_arguments. */
- char *(*set_arguments) (struct gcc_base_context *self,
- const char *triplet_regexp,
- int argc, char **argv);
+ char *(*set_arguments_v0) (struct gcc_base_context *self,
+const char *triplet_regexp,
+int argc, char **argv);
/* Set the file name of the program to compile. The string is
copied by the method implementation, but the caller must
@@ -125,6 +119,45 @@ struct gcc_base_vtable
int /* bool */ (*compile) (struct gcc_base_context *self,
const char *filename);
+
+ /* Set the compiler's command-line options for the next compilation.
+ The arguments are copied by GCC. ARGV need not be
+ NULL-terminated. The arguments must be set separately for each
+ compilation; that is, after a compile is requested, the
+ previously-set arguments cannot be reused.
+
+ This returns NULL on success. On failure, returns a malloc()d
+ error message. The caller is responsible for freeing it.
+
+ This method is only available since GCC_FE_VERSION_1. */
+
+ char *(*set_arguments) (struct gcc_base_context *self,
+ int argc, char **argv);
+
+ /* Set TRIPLET_REGEXP as a regular expression that is used to match
+ the configury triplet prefix to the compiler. Calling this method
+ overrides possible previous call of itself or set_driver_filename.
+
+ This returns NULL on success. On failure, returns a malloc()d
+ error message. The caller is responsible for freeing it.
+
+ This method is only available since GCC_FE_VERSION_1. */
+
+ char *(*set_triplet_regexp) (struct gcc_base_context *self,
+ const char *triplet_regexp);
+
+ /* DRIVER_FILENAME should be filename of the gcc compiler driver
+ program. It will be searched in PATH components like
+ TRIPLET_REGEXP. Calling this method overrides possible previous
+ call of itself or set_triplet_regexp.
+
+ This returns NULL on success. On failure, returns a malloc()d
+ error message. The caller is responsible for freeing it.
+
+ This method is only available since GCC_FE_VERSION_1. */
+
+ char *(*set_driver_filename) (struct
[PATCH v3 4/4] libcc1: 'set debug compile': Display absolute GCC driver filename
Hi,
already approved, maybe it could be already checked in outside of the series:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01298.html
With the patches so far after
(gdb) set debug compile 1
one would get:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler x86_64-unknown-linux-gnu-gcc
But I believe it is more readable to see:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler /usr/bin/x86_64-unknown-linux-gnu-gcc
I do not think the change will have functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* findcomp.cc: Include system.h.
(search_dir): Return absolute filename.
---
libcc1/findcomp.cc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libcc1/findcomp.cc b/libcc1/findcomp.cc
index f02b1df..5d49e29 100644
--- a/libcc1/findcomp.cc
+++ b/libcc1/findcomp.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3. If not see
#include libiberty.h
#include xregex.h
#include findcomp.hh
+#include system.h
class scanner
{
@@ -68,7 +69,7 @@ search_dir (const regex_t regexp, const std::string dir,
std::string *result)
{
if (regexec (regexp, filename, 0, NULL, 0) == 0)
{
- *result = filename;
+ *result = dir + DIR_SEPARATOR + filename;
return true;
}
}
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Fri, 24 Apr 2015 00:06:46 +0200, Jeff Law wrote: On 04/18/2015 04:19 AM, Jan Kratochvil wrote: Instead of current: plugin_build_record_type: record_type = make_node (RECORD_TYPE) plugin_build_add_field: add fields to record_type... But there is no qualified_record_type here! plugin_finish_record_or_union: TYPE_SIZE (record_type) etc. ... to finish the type plugin_build_qualified_type: qualified_record_type = build_qualified_type (record_type, ...) [...] I'm a bit surprised the former didn't work, build_qualified_type() will make a copy of the type being created. While the original type gets finished later (added more fields and its final TYPE_SIZE) the copy remains unfinished forever and GCC later crashes trying to access the unfinished copy. but if the latter is working consistently, then I'd stick with it. Yes, it is solved now. Jan
Re: [PATCH v2 2/4] libcc1: set debug compile: Display GCC driver filename
On Thu, 23 Apr 2015 22:38:34 +0200, Jan Kratochvil wrote: Unfortunately this changes libcc1 API in an incompatible way. There is a possibility of a hack to keep the API the same - one could pass -v option explicitly to set_arguments(), set_arguments() could compare the -v string and print the GCC filename accordingly. Then the 'verbose' parameter of compile() would lose its meaning. What do you think? This paragraph is no longer true, 'compile' keeps its parameter duplicate to the new 'set_arguments's one. Jan
[PATCH v2 1/4] libcc1: Introduce GCC_FE_VERSION_1
Hi,
in mail thread
https://sourceware.org/ml/gdb-patches/2015-04/msg00804.html
the idea of breaking libcc1.so compatibility was rejected.
Therefore this patch series implements full backward/forward GCC/GDB ABI
compatibility.
Jan
include/ChangeLog
2015-04-23 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add GCC_FE_VERSION_1.
libcc1/ChangeLog
2015-04-23 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc (vtable): Update to GCC_FE_VERSION_1.
(gcc_c_fe_context): Accept also GCC_FE_VERSION_1.
---
include/gcc-interface.h |3 ++-
libcc1/libcc1.cc|5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index 34010f2..dcfa6ce 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -44,7 +44,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
- GCC_FE_VERSION_0 = 0
+ GCC_FE_VERSION_0 = 0,
+ GCC_FE_VERSION_1 = 1,
};
/* The operations defined by the GCC base API. This is the vtable for
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index 7d7d2c1..99a0fa1 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -504,7 +504,7 @@ libcc1_destroy (struct gcc_base_context *s)
static const struct gcc_base_vtable vtable =
{
- GCC_FE_VERSION_0,
+ GCC_FE_VERSION_1,
libcc1_set_arguments,
libcc1_set_source_file,
libcc1_set_print_callback,
@@ -523,7 +523,8 @@ struct gcc_c_context *
gcc_c_fe_context (enum gcc_base_api_version base_version,
enum gcc_c_api_version c_version)
{
- if (base_version != GCC_FE_VERSION_0 || c_version != GCC_C_FE_VERSION_0)
+ if ((base_version != GCC_FE_VERSION_0 base_version != GCC_FE_VERSION_1)
+ || c_version != GCC_C_FE_VERSION_0)
return NULL;
return new libcc1 (vtable, c_vtable);
[PATCH v2 3/4] libcc1: Add 'set compile-gcc'
Hi,
already approved, reposting just to keep it a part of the series:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01299.html
As discussed in
How to use compile execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new option 'set compile-gcc'.
This patch does not change the libcc1 API as it overloads the triplet_regexp
parameter of GCC's set_arguments according to:
+ if (access (triplet_regexp, X_OK) == 0)
GDB counterpart:
[PATCH v2 2/2] compile: Add 'set compile-gcc'
https://sourceware.org/ml/gdb-patches/2015-04/msg00910.html
Message-ID: 20150423203402.23140.92757.st...@host1.jankratochvil.net
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Describe triplet_regexp parameter overload
for set_arguments.
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc (libcc1_set_arguments): Implement filenames for
triplet_regexp.
---
include/gcc-interface.h |7 -
libcc1/libcc1.cc| 62 +++
2 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index 21cc403..95b9b12 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -46,7 +46,9 @@ enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
- /* Parameter verbose has been moved from compile to set_arguments. */
+ /* Parameter verbose has been moved from compile to set_arguments.
+ Parameter triplet_regexp of set_arguments can be also gcc driver
+ executable. */
GCC_FE_VERSION_1 = 1,
};
@@ -104,7 +106,8 @@ struct gcc_base_vtable
/* Set the compiler's command-line options for the next compilation.
TRIPLET_REGEXP is a regular expression that is used to match the
- configury triplet prefix to the compiler.
+ configury triplet prefix to the compiler; TRIPLET_REGEXP can be
+ also absolute filename to the computer.
The arguments are copied by GCC. ARGV need not be
NULL-terminated. The arguments must be set separately for each
compilation; that is, after a compile is requested, the
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index 06a91f6..c2a1d5f 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -322,38 +322,48 @@ libcc1_set_arguments (struct gcc_base_context *s,
self-verbose = verbose != 0;
- std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
- // Simulate fnotice by fprintf.
- if (self-verbose)
-fprintf (stderr, _(searching for compiler matching regex %s\n),
-rx.c_str());
- code = regcomp (triplet, rx.c_str (), REG_EXTENDED | REG_NOSUB);
- if (code != 0)
+ std::string compiler;
+ if (access (triplet_regexp, X_OK) == 0)
{
- size_t len = regerror (code, triplet, NULL, 0);
- char err[len];
+ compiler = triplet_regexp;
+ // Simulate fnotice by fprintf.
+ if (self-verbose)
+ fprintf (stderr, _(using explicit compiler filename %s\n),
+compiler.c_str());
+}
+ else
+{
+ std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
+ if (self-verbose)
+ fprintf (stderr, _(searching for compiler matching regex %s\n),
+rx.c_str());
+ code = regcomp (triplet, rx.c_str (), REG_EXTENDED | REG_NOSUB);
+ if (code != 0)
+ {
+ size_t len = regerror (code, triplet, NULL, 0);
+ char err[len];
- regerror (code, triplet, err, len);
+ regerror (code, triplet, err, len);
- return concat (Could not compile regexp \,
-rx.c_str (),
-\: ,
-err,
-(char *) NULL);
-}
+ return concat (Could not compile regexp \,
+rx.c_str (),
+\: ,
+err,
+(char *) NULL);
+ }
- std::string compiler;
- if (!find_compiler (triplet, compiler))
-{
+ if (!find_compiler (triplet, compiler))
+ {
+ regfree (triplet);
+ return concat (Could not find a compiler matching \,
+rx.c_str (),
+\,
+(char *) NULL);
+ }
regfree (triplet);
- return concat (Could not find a compiler matching \,
-rx.c_str (),
-\,
-(char *) NULL);
+ if (self-verbose)
+ fprintf (stderr, _(found compiler %s\n), compiler.c_str());
}
- regfree (triplet);
- if (self-verbose)
-fprintf (stderr, _(found compiler %s\n), compiler.c_str());
self-args.push_back (compiler);
[PATCH v2 2/4] libcc1: set debug compile: Display GCC driver filename
Hi,
already approved, reposting just to keep it a part of the series:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01301.html
As discussed in
How to use compile execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not
display which one. It cannot, GCC method set_arguments() does not yet know
whether 'set debug compile' is enabled or not.
Unfortunately this changes libcc1 API in an incompatible way. There is
a possibility of a hack to keep the API the same - one could pass -v option
explicitly to set_arguments(), set_arguments() could compare the -v string
and print the GCC filename accordingly. Then the 'verbose' parameter of
compile() would lose its meaning. What do you think?
GDB counterpart:
[PATCH v2 1/2] compile: set debug compile: Display GCC driver filename
https://sourceware.org/ml/gdb-patches/2015-04/msg00909.html
Message-ID: 20150423203402.23140.92757.st...@host1.jankratochvil.net
Jan
include/ChangeLog
2015-04-23 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Rename set_arguments to set_arguments_v0.
Update comment for compile. New method set_arguments.
libcc1/ChangeLog
2015-04-23 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc: Include intl.h.
(struct libcc1): Add field verbose.
(libcc1::libcc1): Initialize it.
(libcc1_set_arguments): Add parameter verbose, implement it.
(libcc1_set_arguments_v0): New function.
(libcc1_compile): Set parameter verbose to SELF.
(vtable): Use libcc1_set_arguments_v0 and add libcc1_set_arguments.
---
include/gcc-interface.h | 45 +
libcc1/libcc1.cc| 34 +-
2 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index dcfa6ce..21cc403 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -45,6 +45,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
+
+ /* Parameter verbose has been moved from compile to set_arguments. */
GCC_FE_VERSION_1 = 1,
};
@@ -65,20 +67,13 @@ struct gcc_base_vtable
unsigned int version;
- /* Set the compiler's command-line options for the next compilation.
- TRIPLET_REGEXP is a regular expression that is used to match the
- configury triplet prefix to the compiler.
- The arguments are copied by GCC. ARGV need not be
- NULL-terminated. The arguments must be set separately for each
- compilation; that is, after a compile is requested, the
- previously-set arguments cannot be reused.
-
- This returns NULL on success. On failure, returns a malloc()d
- error message. The caller is responsible for freeing it. */
+ /* Deprecated GCC_FE_VERSION_0 variant of the GCC_FE_VERSION_1
+ set_arguments method. GCC_FE_VERSION_0 version did not have the
+ verbose parameter. */
- char *(*set_arguments) (struct gcc_base_context *self,
- const char *triplet_regexp,
- int argc, char **argv);
+ char *(*set_arguments_v0) (struct gcc_base_context *self,
+const char *triplet_regexp,
+int argc, char **argv);
/* Set the file name of the program to compile. The string is
copied by the method implementation, but the caller must
@@ -95,9 +90,9 @@ struct gcc_base_vtable
void *datum);
/* Perform the compilation. FILENAME is the name of the resulting
- object file. VERBOSE can be set to cause GCC to print some
- information as it works. Returns true on success, false on
- error. */
+ object file. VERBOSE should be the same value as passed
+ to gcc_base_vtable::set_arguments. Returns true on success, false
+ on error. */
int /* bool */ (*compile) (struct gcc_base_context *self,
const char *filename,
@@ -106,6 +101,24 @@ struct gcc_base_vtable
/* Destroy this object. */
void (*destroy) (struct gcc_base_context *self);
+
+ /* Set the compiler's command-line options for the next compilation.
+ TRIPLET_REGEXP is a regular expression that is used to match the
+ configury triplet prefix to the compiler.
+ The arguments are copied by GCC. ARGV need not be
+ NULL-terminated. The arguments must be set separately for each
+ compilation; that is, after a compile is requested, the
+ previously-set arguments cannot be reused. VERBOSE can be set
+ to cause GCC to print some information as it works.
+
+ This returns NULL on success. On failure, returns a malloc()d
+ error message. The caller is responsible
[PATCH v2 4/4] libcc1: 'set debug compile': Display absolute GCC driver filename
Hi,
already approved, maybe it could be already checked in outside of the series:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01298.html
With the patches so far after
(gdb) set debug compile 1
one would get:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler x86_64-unknown-linux-gnu-gcc
But I believe it is more readable to see:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler /usr/bin/x86_64-unknown-linux-gnu-gcc
I do not think the change will have functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* findcomp.cc: Include system.h.
(search_dir): Return absolute filename.
---
libcc1/findcomp.cc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libcc1/findcomp.cc b/libcc1/findcomp.cc
index f02b1df..5d49e29 100644
--- a/libcc1/findcomp.cc
+++ b/libcc1/findcomp.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3. If not see
#include libiberty.h
#include xregex.h
#include findcomp.hh
+#include system.h
class scanner
{
@@ -68,7 +69,7 @@ search_dir (const regex_t regexp, const std::string dir,
std::string *result)
{
if (regexec (regexp, filename, 0, NULL, 0) == 0)
{
- *result = filename;
+ *result = dir + DIR_SEPARATOR + filename;
return true;
}
}
[PATCH 2/5] libcc1: Use libcc1.so.0-libcc1.so.1
Hi,
see [patch 1/5], particularly:
(3) Currently there is no backward or forward compatibility although there
could be one implemented. Personally I think the 'compile' feature is
still in experimental stage so that it is OK to require last releases.
At least in Fedora we can keep GDB-GCC in sync.
GDB counterpart:
[PATCH 2/4] compile: Use libcc1.so.0-libcc1.so.1
https://sourceware.org/ml/gdb-patches/2015-04/msg00806.html
Message-ID: 20150421213642.14147.93210.st...@host1.jankratochvil.net
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-c-interface.h (GCC_C_FE_LIBCC): Update it to GCC_FE_VERSION_1.
* gcc-interface.h (enum gcc_base_api_version): Add GCC_FE_VERSION_1.
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* Makefile.am (libcc1_la_LDFLAGS): Add version-info 1.
* Makefile.in: Regenerate.
* libcc1.cc (vtable, gcc_c_fe_context): Update it to GCC_FE_VERSION_1.
---
include/gcc-c-interface.h |2 +-
include/gcc-interface.h |3 ++-
libcc1/Makefile.am|3 ++-
libcc1/Makefile.in|4 +++-
libcc1/libcc1.cc |4 ++--
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/gcc-c-interface.h b/include/gcc-c-interface.h
index 1b73e32..285c9c7 100644
--- a/include/gcc-c-interface.h
+++ b/include/gcc-c-interface.h
@@ -197,7 +197,7 @@ struct gcc_c_context
/* The name of the .so that the compiler builds. We dlopen this
later. */
-#define GCC_C_FE_LIBCC libcc1.so. STRINGIFY (GCC_FE_VERSION_0)
+#define GCC_C_FE_LIBCC libcc1.so. STRINGIFY (GCC_FE_VERSION_1)
/* The compiler exports a single initialization function. This macro
holds its name as a symbol. */
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index 34010f2..dcfa6ce 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -44,7 +44,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
- GCC_FE_VERSION_0 = 0
+ GCC_FE_VERSION_0 = 0,
+ GCC_FE_VERSION_1 = 1,
};
/* The operations defined by the GCC base API. This is the vtable for
diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
index 7a274b3..e6a94e2 100644
--- a/libcc1/Makefile.am
+++ b/libcc1/Makefile.am
@@ -63,7 +63,8 @@ libcc1plugin_la_LINK = $(LIBTOOL) --tag=CXX
$(AM_LIBTOOLFLAGS) \
$(CXXFLAGS) $(libcc1plugin_la_LDFLAGS) $(LTLDFLAGS) -o $@
LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
-libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym
+libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym \
+ -version-info 1:0:0
libcc1_la_SOURCES = findcomp.cc libcc1.cc names.cc names.hh $(shared_source)
libcc1_la_LIBADD = $(libiberty)
libcc1_la_DEPENDENCIES = $(libiberty_dep)
diff --git a/libcc1/Makefile.in b/libcc1/Makefile.in
index 1916134..ebec54c 100644
--- a/libcc1/Makefile.in
+++ b/libcc1/Makefile.in
@@ -279,7 +279,9 @@ libcc1plugin_la_LINK = $(LIBTOOL) --tag=CXX
$(AM_LIBTOOLFLAGS) \
$(CXXFLAGS) $(libcc1plugin_la_LDFLAGS) $(LTLDFLAGS) -o $@
LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
-libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym
+libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym \
+ -version-info 1:0:0
+
libcc1_la_SOURCES = findcomp.cc libcc1.cc names.cc names.hh $(shared_source)
libcc1_la_LIBADD = $(libiberty)
libcc1_la_DEPENDENCIES = $(libiberty_dep)
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index 7d7d2c1..afda023 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -504,7 +504,7 @@ libcc1_destroy (struct gcc_base_context *s)
static const struct gcc_base_vtable vtable =
{
- GCC_FE_VERSION_0,
+ GCC_FE_VERSION_1,
libcc1_set_arguments,
libcc1_set_source_file,
libcc1_set_print_callback,
@@ -523,7 +523,7 @@ struct gcc_c_context *
gcc_c_fe_context (enum gcc_base_api_version base_version,
enum gcc_c_api_version c_version)
{
- if (base_version != GCC_FE_VERSION_0 || c_version != GCC_C_FE_VERSION_0)
+ if (base_version != GCC_FE_VERSION_1 || c_version != GCC_C_FE_VERSION_0)
return NULL;
return new libcc1 (vtable, c_vtable);
[PATCH 3/5] libcc1: set debug compile: Display GCC driver filename
Hi,
as discussed in
How to use compile execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not
display which one. It cannot, GCC method set_arguments() does not yet know
whether 'set debug compile' is enabled or not.
Unfortunately this changes libcc1 API in an incompatible way. There is
a possibility of a hack to keep the API the same - one could pass -v option
explicitly to set_arguments(), set_arguments() could compare the -v string
and print the GCC filename accordingly. Then the 'verbose' parameter of
compile() would lose its meaning. What do you think?
GDB counterpart:
[PATCH 3/4] compile: set debug compile: Display GCC driver filename
https://sourceware.org/ml/gdb-patches/2015-04/msg00807.html
Message-ID: 20150421213649.14147.79719.st...@host1.jankratochvil.net
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Move parameter verbose from compile to
set_arguments.
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc: Include intl.h.
(struct libcc1): Add field verbose.
(libcc1::libcc1): Initialize it.
(libcc1_set_arguments): Add parameter verbose, implement it.
(libcc1_compile): Remove parameter verbose, use self's field instead.
---
include/gcc-interface.h | 14 +++---
libcc1/libcc1.cc| 22 +-
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index dcfa6ce..dd9fd50 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -45,6 +45,8 @@ struct gcc_base_context;
enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
+
+ /* Parameter verbose has been moved from compile to set_arguments. */
GCC_FE_VERSION_1 = 1,
};
@@ -71,14 +73,15 @@ struct gcc_base_vtable
The arguments are copied by GCC. ARGV need not be
NULL-terminated. The arguments must be set separately for each
compilation; that is, after a compile is requested, the
- previously-set arguments cannot be reused.
+ previously-set arguments cannot be reused. VERBOSE can be set
+ to cause GCC to print some information as it works.
This returns NULL on success. On failure, returns a malloc()d
error message. The caller is responsible for freeing it. */
char *(*set_arguments) (struct gcc_base_context *self,
const char *triplet_regexp,
- int argc, char **argv);
+ int argc, char **argv, int /* bool */ verbose);
/* Set the file name of the program to compile. The string is
copied by the method implementation, but the caller must
@@ -95,13 +98,10 @@ struct gcc_base_vtable
void *datum);
/* Perform the compilation. FILENAME is the name of the resulting
- object file. VERBOSE can be set to cause GCC to print some
- information as it works. Returns true on success, false on
- error. */
+ object file. Returns true on success, false on error. */
int /* bool */ (*compile) (struct gcc_base_context *self,
-const char *filename,
-int /* bool */ verbose);
+const char *filename);
/* Destroy this object. */
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index afda023..d36073d 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3. If not see
#include xregex.h
#include findcomp.hh
#include compiler-name.h
+#include intl.h
struct libcc1;
@@ -66,6 +67,9 @@ struct libcc1 : public gcc_c_context
std::vectorstd::string args;
std::string source_file;
+
+ /* Non-zero as an equivalent to gcc driver option -v. */
+ bool verbose;
};
// A local subclass of connection that holds a back-pointer to the
@@ -97,7 +101,8 @@ libcc1::libcc1 (const gcc_base_vtable *v,
print_function (NULL),
print_datum (NULL),
args (),
-source_file ()
+source_file (),
+verbose (false)
{
base.ops = v;
c_ops = cv;
@@ -309,13 +314,19 @@ make_regexp (const char *triplet_regexp, const char
*compiler)
static char *
libcc1_set_arguments (struct gcc_base_context *s,
const char *triplet_regexp,
- int argc, char **argv)
+ int argc, char **argv, int verbose)
{
libcc1 *self = (libcc1 *) s;
regex_t triplet;
int code;
+ self-verbose = verbose != 0;
+
std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
+ // Simulate fnotice by fprintf.
+ if (self-verbose)
+fprintf (stderr, _(searching for compiler matching regex %s\n
[PATCH 1/5] libcc1: Make libcc1.so-libcc1.so.0
Hi, the next [patch 3/5] will change the libcc1.so API. I am not sure if the API change gets approved that way but for such case: (1) We really need to change GCC_FE_VERSION_0 - GCC_FE_VERSION_1, this feature is there for this purpose. That is [patch 2/5]. (2) Currently GDB does only dlopen(libcc1.so) and then depending on which libcc1.so version it would find first it would succeed/fail. I guess it is more convenient to do dlopen(libcc1.so.1) instead (where .1=.x corresponds to GCC_FE_VERSION_x). That is this patch (with x=0). GCC_C_FE_LIBCC is used only by GDB. (3) Currently there is no backward or forward compatibility although there could be one implemented. Personally I think the 'compile' feature is still in experimental stage so that it is OK to require last releases. At least in Fedora we can keep GDB-GCC in sync. GDB counterpart: [PATCH 1/4] compile: Use libcc1.so-libcc1.so.0 https://sourceware.org/ml/gdb-patches/2015-04/msg00805.html Message-ID: 20150421213635.14147.15653.st...@host1.jankratochvil.net Jan include/ChangeLog 2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com * gcc-c-interface.h (GCC_C_FE_LIBCC): Quote it. Append GCC_FE_VERSION_0. --- include/gcc-c-interface.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/gcc-c-interface.h b/include/gcc-c-interface.h index 25ef62f..1b73e32 100644 --- a/include/gcc-c-interface.h +++ b/include/gcc-c-interface.h @@ -197,7 +197,7 @@ struct gcc_c_context /* The name of the .so that the compiler builds. We dlopen this later. */ -#define GCC_C_FE_LIBCC libcc1.so +#define GCC_C_FE_LIBCC libcc1.so. STRINGIFY (GCC_FE_VERSION_0) /* The compiler exports a single initialization function. This macro holds its name as a symbol. */
[PATCH 4/5] libcc1: Add 'set compile-gcc'
as discussed in
How to use compile execute function in GDB
https://sourceware.org/ml/gdb/2015-04/msg00026.html
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new option 'set compile-gcc'.
This patch does not change the libcc1 API as it overloads the triplet_regexp
parameter of GCC's set_arguments according to:
+ if (access (triplet_regexp, X_OK) == 0)
GDB counterpart:
[PATCH 4/4] compile: Add 'set compile-gcc'
https://sourceware.org/ml/gdb-patches/2015-04/msg00808.html
Message-ID: 20150421213657.14147.60506.st...@host1.jankratochvil.net
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Describe triplet_regexp parameter overload
for set_arguments.
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* libcc1.cc (libcc1_set_arguments): Implement filenames for
triplet_regexp.
---
include/gcc-interface.h |7 -
libcc1/libcc1.cc| 62 +++
2 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/include/gcc-interface.h b/include/gcc-interface.h
index dd9fd50..a15edf7 100644
--- a/include/gcc-interface.h
+++ b/include/gcc-interface.h
@@ -46,7 +46,9 @@ enum gcc_base_api_version
{
GCC_FE_VERSION_0 = 0,
- /* Parameter verbose has been moved from compile to set_arguments. */
+ /* Parameter verbose has been moved from compile to set_arguments.
+ Parameter triplet_regexp of set_arguments can be also gcc driver
+ executable. */
GCC_FE_VERSION_1 = 1,
};
@@ -69,7 +71,8 @@ struct gcc_base_vtable
/* Set the compiler's command-line options for the next compilation.
TRIPLET_REGEXP is a regular expression that is used to match the
- configury triplet prefix to the compiler.
+ configury triplet prefix to the compiler; TRIPLET_REGEXP can be
+ also absolute filename to the computer.
The arguments are copied by GCC. ARGV need not be
NULL-terminated. The arguments must be set separately for each
compilation; that is, after a compile is requested, the
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
index d36073d..e2718b0 100644
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -322,38 +322,48 @@ libcc1_set_arguments (struct gcc_base_context *s,
self-verbose = verbose != 0;
- std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
- // Simulate fnotice by fprintf.
- if (self-verbose)
-fprintf (stderr, _(searching for compiler matching regex %s\n),
-rx.c_str());
- code = regcomp (triplet, rx.c_str (), REG_EXTENDED | REG_NOSUB);
- if (code != 0)
+ std::string compiler;
+ if (access (triplet_regexp, X_OK) == 0)
{
- size_t len = regerror (code, triplet, NULL, 0);
- char err[len];
+ compiler = triplet_regexp;
+ // Simulate fnotice by fprintf.
+ if (self-verbose)
+ fprintf (stderr, _(using explicit compiler filename %s\n),
+compiler.c_str());
+}
+ else
+{
+ std::string rx = make_regexp (triplet_regexp, COMPILER_NAME);
+ if (self-verbose)
+ fprintf (stderr, _(searching for compiler matching regex %s\n),
+rx.c_str());
+ code = regcomp (triplet, rx.c_str (), REG_EXTENDED | REG_NOSUB);
+ if (code != 0)
+ {
+ size_t len = regerror (code, triplet, NULL, 0);
+ char err[len];
- regerror (code, triplet, err, len);
+ regerror (code, triplet, err, len);
- return concat (Could not compile regexp \,
-rx.c_str (),
-\: ,
-err,
-(char *) NULL);
-}
+ return concat (Could not compile regexp \,
+rx.c_str (),
+\: ,
+err,
+(char *) NULL);
+ }
- std::string compiler;
- if (!find_compiler (triplet, compiler))
-{
+ if (!find_compiler (triplet, compiler))
+ {
+ regfree (triplet);
+ return concat (Could not find a compiler matching \,
+rx.c_str (),
+\,
+(char *) NULL);
+ }
regfree (triplet);
- return concat (Could not find a compiler matching \,
-rx.c_str (),
-\,
-(char *) NULL);
+ if (self-verbose)
+ fprintf (stderr, _(found compiler %s\n), compiler.c_str());
}
- regfree (triplet);
- if (self-verbose)
-fprintf (stderr, _(found compiler %s\n), compiler.c_str());
self-args.push_back (compiler);
[PATCH 5/5] libcc1: 'set debug compile': Display absolute GCC driver filename
Hi,
with the patches so far after
(gdb) set debug compile 1
one would get:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler x86_64-unknown-linux-gnu-gcc
But I believe it is more readable to see:
searching for compiler matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler /usr/bin/x86_64-unknown-linux-gnu-gcc
I do not think the change will have functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-04-21 Jan Kratochvil jan.kratoch...@redhat.com
* findcomp.cc: Include system.h.
(search_dir): Return absolute filename.
---
libcc1/findcomp.cc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libcc1/findcomp.cc b/libcc1/findcomp.cc
index f02b1df..5d49e29 100644
--- a/libcc1/findcomp.cc
+++ b/libcc1/findcomp.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3. If not see
#include libiberty.h
#include xregex.h
#include findcomp.hh
+#include system.h
class scanner
{
@@ -68,7 +69,7 @@ search_dir (const regex_t regexp, const std::string dir,
std::string *result)
{
if (regexec (regexp, filename, 0, NULL, 0) == 0)
{
- *result = filename;
+ *result = dir + DIR_SEPARATOR + filename;
return true;
}
}
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Fri, 17 Apr 2015 17:22:13 +0200, Jan Kratochvil wrote:
How to get 'volatile struct sv' GCC 'tree' type for:
volatile struct sv { volatile struct sv *p; };
I have found out how it can work, even with no change on the GCC side:
Instead of current:
plugin_build_record_type:
record_type = make_node (RECORD_TYPE)
plugin_build_add_field:
add fields to record_type... But there is no
qualified_record_type here!
plugin_finish_record_or_union:
TYPE_SIZE (record_type) etc. ... to finish the type
plugin_build_qualified_type:
qualified_record_type = build_qualified_type (record_type, ...)
one can do instead:
plugin_build_record_type:
record_type = make_node (RECORD_TYPE)
plugin_build_qualified_type:
qualified_record_type = build_qualified_type (record_type, ...)
plugin_build_add_field:
add fields to qualified_record_type
plugin_finish_record_or_union:
TYPE_SIZE (qualified_record_type) etc. ... to finish the type
And one forgets about the unfinished record_type.
For a different cv-quals of the same record type one builds a new cv-qualified
record from scratch.
Jan
ping: [gcc patch] libcc1: '@' GDB array operator
Hi, ping: [gcc patch] libcc1: '@' GDB array operator https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html Message-ID: 20150327163646.ga16...@host1.jankratochvil.net Jan
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Tue, 14 Apr 2015 08:09:05 +0200, Jan Kratochvil wrote:
On Fri, 10 Apr 2015 14:31:45 +0200, Jan Kratochvil wrote:
What is the recommended fix? I expect pointer to a declaration / opaque
type
which gets completed only when one references the 'p' field later?
It looks as it got fixed by:
It did not.
As I was told the mail was unclear - to simplify the question:
How to get 'volatile struct sv' GCC 'tree' type for:
volatile struct sv { volatile struct sv *p; };
Thanks,
Jan
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Fri, 10 Apr 2015 14:31:45 +0200, Jan Kratochvil wrote:
What is the recommended fix? I expect pointer to a declaration / opaque type
which gets completed only when one references the 'p' field later?
It looks as it got fixed by:
-plugin_build_record_type (cc1_plugin::connection *self)
+plugin_build_record_type (cc1_plugin::connection *self, const char *name)
{
plugin_context *ctx = static_castplugin_context * (self);
- return convert_out (ctx-preserve (make_node (RECORD_TYPE)));
+ tree node (make_node (RECORD_TYPE));
+ tree type_decl (build_decl (input_location, TYPE_DECL, get_identifier (name),
+ node));
+ TYPE_NAME (node) = type_decl;
+ TYPE_STUB_DECL (node) = type_decl;
+ C_TYPE_BEING_DEFINED (node) = 1;
+ return convert_out (ctx-preserve (node));
Jan
[gcc patch] libcc1: '@' GDB array operator
Hi,
there is now pending GDB patch for: (gdb) compile print EXPR
[PATCH 4/4] compile: New 'compile print'
https://sourceware.org/ml/gdb-patches/2015-03/msg00875.html
Reasons for this patch:
How to implement '@' GDB-like operator for libcc1
https://gcc.gnu.org/ml/gcc/2015-03/msg00175.html
Testcase is in the GDB patch. There could be a testcase in the 'guality' part
of GCC testsuite.
I have some doubts if the copy_node() way is right.
The error for stray '@' is now reported elsewhere so for example
int a=1@a;
produced
stray.c:1:8: error: stray ‘@’ in program
int a=1@a;
^
stray.c:1:9: error: expected ‘,’ or ‘;’ before ‘a’
int a=1@a;
^
but now it produces:
stray.c:1:8: error: stray ‘@’ in program
int a=1@a;
^
stray.c:1:8: error: expected ‘,’ or ‘;’ before ‘@’ token
It is because in c-family/c-common.c we cannot yet access c_binding_oracle
(whether GDB is present) as c_binding_oracle is c-specific symbol while
c-family/c-common.c is linked for both c and c++; so c_binding_oracle symbol
is missing when linking cc1plus. As there should be also C++ support for
libcc1 in the future c_binding_oracle will need to be present for both C and
C++. But so far I have left it as submitted.
GCC testsuite has passed without regressions.
Thanks,
Jan
gcc/c-family/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* c-common.c (c_fully_fold_internal, binary_op_error): Add ATSIGN_EXPR.
* c-lex.c (c_lex_with_flags): Add ATSIGN_EXPR.
gcc/c/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* c-parser.c (enum c_parser_prec): Add PREC_ATSIGN.
(c_parser_binary_expression): Add CPP_ATSIGN.
* c-typeck.c (build_binary_op): Add ATSIGN_EXPR.
gcc/
2015-03-27 Jan Kratochvil jan.kratoch...@redhat.com
* tree-pretty-print.c (dump_generic_node, op_symbol_code): Add
ATSIGN_EXPR.
* tree.def: Add ATSIGN_EXPR.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 456c619..37cb104c 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -1289,6 +1289,28 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
ret = fold (ret);
goto out;
+case ATSIGN_EXPR:
+ orig_op0 = op0 = TREE_OPERAND (expr, 0);
+ orig_op1 = op1 = TREE_OPERAND (expr, 1);
+ op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
+ maybe_const_itself);
+ STRIP_TYPE_NOPS (op0);
+ op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
+ maybe_const_itself);
+ STRIP_TYPE_NOPS (op1);
+ op1 = decl_constant_value_for_optimization (op1);
+ ret = copy_node (op0);
+ TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0),
+ tree_to_uhwi (op1));
+ if (ret != expr)
+ {
+ TREE_READONLY (ret) = TREE_READONLY (expr);
+ TREE_SIDE_EFFECTS (ret) = TREE_SIDE_EFFECTS (expr);
+ TREE_THIS_VOLATILE (ret) = TREE_THIS_VOLATILE (expr);
+ }
+ ret = fold (ret);
+ goto out;
+
case COMPOUND_EXPR:
case MODIFY_EXPR:
case PREDECREMENT_EXPR:
@@ -4084,6 +4106,8 @@ binary_op_error (location_t location, enum tree_code code,
opname = ||; break;
case BIT_XOR_EXPR:
opname = ^; break;
+case ATSIGN_EXPR:
+ opname = @; break;
default:
gcc_unreachable ();
}
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index bb55be8..3a9f968 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -515,7 +515,10 @@ c_lex_with_flags (tree *value, location_t *loc, unsigned
char *cpp_flags,
break;
}
- /* FALLTHROUGH */
+ // Create ATSIGN_EXPR for GDB.
+ *value = NULL_TREE;
+ break;
+
case CPP_HASH:
case CPP_PASTE:
{
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 5cc3892..2a30d72 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1173,6 +1173,7 @@ enum c_parser_prec {
PREC_EQ,
PREC_REL,
PREC_SHIFT,
+ PREC_ATSIGN,
PREC_ADD,
PREC_MULT,
NUM_PRECS
@@ -6283,6 +6284,16 @@ c_parser_binary_expression (c_parser *parser, struct
c_expr *after,
oprec = PREC_ADD;
ocode = MINUS_EXPR;
break;
+ case CPP_ATSIGN:
+ if (!c_binding_oracle)
+ {
+ error_at (c_parser_peek_token (parser)-location,
+ stray %qs in program, @);
+ goto out;
+ }
+ oprec = PREC_ATSIGN;
+ ocode = ATSIGN_EXPR;
+ break;
case CPP_LSHIFT:
oprec = PREC_SHIFT;
ocode = LSHIFT_EXPR;
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index ebe4c73..22e7bd8 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10976,6 +10976,19 @@ build_binary_op
Re: How to implement '@' GDB-like operator for libcc1
On Mon, 16 Mar 2015 15:43:21 +0100, Tom Tromey wrote: It seems like there should be some kind of reference to op0, that is, lowering ATSIGN_EXPR to *(typeof(OP0)[OP1]*)(OP0). OK, I got it now. I was using GDB-like 'struct type *' where 'struct value *' should have been as in GCC both are 'tree'. After fixing that it started working: https://github.com/jankratochvil/gcc/commit/abe7d19e06d4daed79720cd1465a1f87763d2095 ret = copy_node (op0); TREE_TYPE (ret) = build_array_type_nelts (TREE_TYPE (op0), tree_to_uhwi (op1)); Also, I this has to consider the case where OP1 is not a constant. I find that already checked in gcc/c/c-typeck.c . Thanks, Jan
Re: How to implement '@' GDB-like operator for libcc1
On Mon, 16 Mar 2015 10:33:26 +0100, Manuel López-Ibáñez wrote:
On 16 March 2015 at 09:32, Jan Kratochvil jan.kratoch...@redhat.com wrote:
On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
Thus, the question is what info GDB needs from GCC to be able to print
the contents of the array.
Variable with an array type in DWARF.
How does it work then for pointers?
int *p = malloc(...);
(gdb) p *p@3
should also work.
The idea was GCC would create an int[3] __gdb_expr_val variable for the result
and GDB would read that int[3] type from __gdb_expr_val's DWARF.
And it probably just needs the type of whatever is to the left of @ and the
value of whatever is to the right of @, no?
There are two ways how to fix that. As '@' makes sense only at the
outermost
operator of an expression GDB could strip it and not to pass it to GCC at
all.
But then there would be unhandled corner cases like parentheses:
(gdb) print (*a@3)
Would it be so difficult to strip parentheses? I honestly think it
might be easier than adding special handling for @ to the C parser.
If it is really difficult to implement '@' in GCC then yes, that's the other
way. I expected to learn GCC parser on this IMO-simpler case so one can later
implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
protections, FILE::VARIABLE or FUNCTION::VARIABLE notations etc. So there are
more topics for the C/C++ parser but I tried this one first.
I think there are more options: GDB could also convert @ to something
that GCC can understand, like a function call, or a cast to a
gdb-defined type, and that will trigger the generation of the desired
DWARF.
I do not see how GDB could properly parse the expression with proper operator
priorities/association.
Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB
will
pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly,
one
can see it for:
Would it be possible for GDB to generate code such that this trick is
generated for @? Perhaps by creating a dummy array variable, then
applying typeof(dummy) like you do below.
Sorry I do not get it. GDB does not know how many elements the array should
have without parsing the expression on its own - and only GCC can parse C/C++.
Thanks,
Jan
Re: How to implement '@' GDB-like operator for libcc1
On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
But GDB features a useful custom expression operator '@':
https://sourceware.org/gdb/onlinedocs/gdb/Arrays.html
I have problems implementing '@' into GCC, could you suggest at which place
should I call build_array_type_nelts()? Or is it the right way at all?
Testing it on a sample code - it should return 2:
int a[]={1,2,3};int main(void){ return (*a@3)[1]; }
Sorry if I'm missing something, but this example does not make sense
to me. You can directly use a[1], no need for the @-operator here.
You are right but I did not want to complicate the reproducer by an interface
to GDB.
In my experience (and again, sorry if I'm missing other interesting
usercases), the utility of @ is to be able to do things like:
print a@3
print (*(something complicated expression))@(some integer expression)
Yes although it is missing one dereference, that is it should be:
print *a@3
print (*(something complicated expression))@(some integer expression)
I agree it is a bit counter-intuitive but this is how existing GDB '@'
operator works.
Thus, the question is what info GDB needs from GCC to be able to print
the contents of the array.
Variable with an array type in DWARF.
And it probably just needs the type of whatever is to the left of @ and the
value of whatever is to the right of @, no?
There are two ways how to fix that. As '@' makes sense only at the outermost
operator of an expression GDB could strip it and not to pass it to GCC at all.
But then there would be unhandled corner cases like parentheses:
(gdb) print (*a@3)
So I tried to implement '@' as a proper GCC operator so that GCC creates full
array type in the DWARF.
Then there also is an option to hook GDB somewhere into the expression parser
of GCC. GDB currently implements 'compile print' just by compiling a special
generated .c file into .o and running .o + parsing the .o's DWARF to find the
proper type, see below.
Also note that given this code and breaking in main()
int a[]={1,2,3};int main(void){ return (a[1]); }
then:
(gdb) p a
$1 = {1, 2, 3}
(gdb) p a@3
$2 = {{1, 2, 3}, {0, 0, 0}, {0, 0, 0}}
This is because:
(gdb) ptype a
type = int [3]
(gdb) ptype a@3
type = int [3][3]
There is missing one *:
(gdb) p a
$1 = {1, 2, 3}
(gdb) p *a@3
$2 = {1, 2, 3}
(gdb) ptype a
type = int [3]
(gdb) ptype *a@3
type = int [3]
Thus, what happens currently when you do?
(gdb) compile int a[]={1,2,3}
(gdb) compile print a
(gdb) compile int a[]={1,2,3}
(gdb) compile print a
gdb command line:1:30: error: ‘a’ undeclared (first use in this function)
Because the compiled modules info is not persistent. But with 'a' defined in
the inferior program one gets:
(gdb) compile print a
{1, 2, 3}
You may guess there is already a hack for this case, GDB compiles for
the 'compile print' command following stub:
void _gdb_expr (struct __gdb_regs *__regs, void * __gdb_out_param, int
__gdb_expr_take_address) {
__auto_type __gdb_expr_val = /***The expression:***/ a;
typeof (/***The expression:***/ a) *__gdb_expr_ptr_type;
if (__gdb_expr_take_address)
memcpy (__gdb_out_param, __gdb_expr_val, sizeof
(*__gdb_expr_ptr_type));
else
memcpy (__gdb_out_param, __gdb_expr_val, sizeof
(*__gdb_expr_ptr_type));
}
Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB will
pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, one
can see it for:
(gdb) l
1 int main(void) {
2 int i=0; __auto_type i_val=i; typeof(i) *i_ptr_type;
3 int a[]={1,2,3}; __auto_type a_val=a; typeof(a) *a_ptr_type;
4 return 0; }
(gdb) ptype i_val
type = int
(gdb) ptype i_ptr_type
type = int *
- i_ptr_type == i_val * = __gdb_expr_take_address=true
(gdb) ptype a_val
type = int *
(gdb) ptype a_ptr_type
type = int (*)[3]
- i_ptr_type == (*i_val)* i_val is array =
__gdb_expr_take_address=false
Implemented by:
https://github.com/tromey/gdb/commit/6ec13bc75ebbaa3b5fab8ecda8518af56cc5e2e8
Before this auto-detection GDB would print only pointers, not arrays:
(gdb) l
1 int a[]={1,2,3,4,5};
(gdb) print a
$1 = {1, 2, 3, 4, 5}
(gdb) compile print a
(int *) 0x601040 a
The problem is that '__auto_type' does not preserve the array type,
'__auto_type' converts arrays to pointers. When I tried to fix that in
attached auto_type.patch GCC would error on such assignment
__auto_type a_val=a;
with:
gdb command line:1:30: error: array initialized from non-constant array
expression
Thanks,
Jan
gdb command line:1:30: error: array initialized from non-constant array
expression
including converting functions and arrays to pointers if CONVERT_P.
struct c_expr
How to implement '@' GDB-like operator for libcc1
Hi,
based on the GCC libcc1 plugin GDB will implement GDB command 'compile print'
equivalent to default 'print' but evaluating the expression by GCC:
https://github.com/tromey/gdb/tree/pmuldoon/compile/print
It is currently done by compiling a .c-.o file and checking its DWARF for the
type and size of the resulting object to print.
But GDB features a useful custom expression operator '@':
https://sourceware.org/gdb/onlinedocs/gdb/Arrays.html
I have problems implementing '@' into GCC, could you suggest at which place
should I call build_array_type_nelts()? Or is it the right way at all?
Testing it on a sample code - it should return 2:
int a[]={1,2,3};int main(void){ return (*a@3)[1]; }
Proper overloading of '@' to keep it working for ObjC and/or enabling '@' only
for libcc1 I find currently off-topic.
With both c_fully_fold_internal() and gimplify_modify_expr_rhs() hooks #if 0-ed
(as they are in the attached patch) GCC crashes on infinite loop:
-gimplify_expr-gimplify_modify_expr-gimplify_expr-gimplify_stmt-
-gimplify_and_add-internal_get_tmp_var-get_formal_tmp_var-
Thanks,
Jan
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 8c23e09..69fa054 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -1289,6 +1289,25 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
ret = fold (ret);
goto out;
+#if 0 // it would crash at array_ref_low_bound()'s first line
+case ATSIGN_EXPR:
+ orig_op0 = op0 = TREE_OPERAND (expr, 0);
+ orig_op1 = op1 = TREE_OPERAND (expr, 1);
+#if 0 // not needed
+ op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
+ maybe_const_itself);
+ STRIP_TYPE_NOPS (op0);
+ op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
+ maybe_const_itself);
+ STRIP_TYPE_NOPS (op1);
+#endif
+ ret = build_array_type_nelts (TREE_TYPE (op0), tree_to_uhwi (op1));
+#if 0 // not needed
+ ret = fold (ret);
+#endif
+ goto out;
+#endif
+
case COMPOUND_EXPR:
case MODIFY_EXPR:
case PREDECREMENT_EXPR:
@@ -4078,6 +4097,8 @@ binary_op_error (location_t location, enum tree_code code,
opname = ||; break;
case BIT_XOR_EXPR:
opname = ^; break;
+case ATSIGN_EXPR:
+ opname = @; break;
default:
gcc_unreachable ();
}
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index bb55be8..ad8b82f 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -468,6 +468,8 @@ c_lex_with_flags (tree *value, location_t *loc, unsigned
char *cpp_flags,
break;
case CPP_ATSIGN:
+ *value = NULL_TREE;
+ break;
/* An @ may give the next token special significance in Objective-C. */
if (c_dialect_objc ())
{
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index ceb9e1a..5d5a0a8 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1173,6 +1173,7 @@ enum c_parser_prec {
PREC_EQ,
PREC_REL,
PREC_SHIFT,
+ PREC_ATSIGN,
PREC_ADD,
PREC_MULT,
NUM_PRECS
@@ -6283,6 +6284,10 @@ c_parser_binary_expression (c_parser *parser, struct
c_expr *after,
oprec = PREC_ADD;
ocode = MINUS_EXPR;
break;
+ case CPP_ATSIGN:
+ oprec = PREC_ATSIGN;
+ ocode = ATSIGN_EXPR;
+ break;
case CPP_LSHIFT:
oprec = PREC_SHIFT;
ocode = LSHIFT_EXPR;
@@ -7082,6 +7087,10 @@ c_parser_postfix_expression (c_parser *parser)
expr.original_type = NULL;
switch (c_parser_peek_token (parser)-type)
{
+case CPP_ATSIGN:
+ error_at (loc, gdbjit hit);
+ expr.value = error_mark_node;
+ break;
case CPP_NUMBER:
expr.value = c_parser_peek_token (parser)-value;
loc = c_parser_peek_token (parser)-location;
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index a3a9c77..0c2f1f9 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10949,6 +10949,14 @@ build_binary_op (location_t location, enum tree_code
code,
maybe_warn_bool_compare (location, code, orig_op0, orig_op1);
break;
+case ATSIGN_EXPR:
+ if (TREE_CODE (orig_op1) == INTEGER_CST)
+ {
+ result_type = build_array_type_nelts (type0, tree_to_uhwi (orig_op1));
+ converted = 1;
+ }
+ break;
+
default:
gcc_unreachable ();
}
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index d822913..b4027dc 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4418,6 +4418,12 @@ gimplify_modify_expr_rhs (tree *expr_p, tree *from_p,
tree *to_p,
return GS_OK;
}
}
+ break;
+
+#if 0 // it would get hit
+ case ATSIGN_EXPR:
+ gcc_unreachable ();
+#endif
default:
break;
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index d7c049f..cf00457 100644
---
[patch] PR other/65366: Fix gdbhooks.py for GDB with Python3
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
GDB Python support upstream has always been compatible with Python3.
Fedora since F-22 builds GDB with Python3 by default (=F-21 GDB used Python2).
gdbhooks.py in GCC trunk is compatible with Python2 but not Python3.
gdb-7.9-10.fc23.x86_64
(gdb) source /home/jkratoch/redhat/gcchead/gcc/c/../gdbhooks.py
File /home/jkratoch/redhat/gcchead/gcc/c/../gdbhooks.py, line 372
print format_[i]
^
SyntaxError: Missing parentheses in call to 'print'
Additionally after fixing the 'print' incompatibility one gets randomly:
dependence_info = {clique = 257, Python Exception class 'NameError' name
'long' is not defined:
base = 1}}}, type = },
OK for check-in?
The long()-int() change I have followed from:
https://stackoverflow.com/questions/14904814/nameerror-global-name-long-is-not-defined/14904834
Thanks,
Jan
2015-03-09 Jan Kratochvil jan.kratoch...@redhat.com
PR other/65366
* gdbhooks.py: Use int(...) instead of long(...). Use print(...)
instead of print ... .
Index: gcc/gdbhooks.py
===
--- gcc/gdbhooks.py (revision 221277)
+++ gcc/gdbhooks.py (working copy)
@@ -158,7 +158,7 @@ class Tree:
self.gdbval = gdbval
def is_nonnull(self):
-return long(self.gdbval)
+return int(self.gdbval)
def TREE_CODE(self):
@@ -197,7 +197,7 @@ class TreePrinter:
# like gcc/print-tree.c:print_node_brief
# #define TREE_CODE(NODE) ((enum tree_code) (NODE)-base.code)
# tree_code_name[(int) TREE_CODE (node)])
-if long(self.gdbval) == 0:
+if int(self.gdbval) == 0:
return 'tree 0x0'
val_TREE_CODE = self.node.TREE_CODE()
@@ -209,17 +209,17 @@ class TreePrinter:
val_tclass = val_tree_code_type[val_TREE_CODE]
val_tree_code_name = gdb.parse_and_eval('tree_code_name')
-val_code_name = val_tree_code_name[long(val_TREE_CODE)]
-#print val_code_name.string()
+val_code_name = val_tree_code_name[int(val_TREE_CODE)]
+#print(val_code_name.string())
-result = '%s 0x%x' % (val_code_name.string(), long(self.gdbval))
-if long(val_tclass) == tcc_declaration:
+result = '%s 0x%x' % (val_code_name.string(), int(self.gdbval))
+if int(val_tclass) == tcc_declaration:
tree_DECL_NAME = self.node.DECL_NAME()
if tree_DECL_NAME.is_nonnull():
result += ' %s' % tree_DECL_NAME.IDENTIFIER_POINTER()
else:
pass # TODO: labels etc
-elif long(val_tclass) == tcc_type:
+elif int(val_tclass) == tcc_type:
tree_TYPE_NAME = Tree(self.gdbval['type_common']['name'])
if tree_TYPE_NAME.is_nonnull():
if tree_TYPE_NAME.TREE_CODE() == IDENTIFIER_NODE:
@@ -242,8 +242,8 @@ class CGraphNodePrinter:
self.gdbval = gdbval
def to_string (self):
-result = 'cgraph_node* 0x%x' % long(self.gdbval)
-if long(self.gdbval):
+result = 'cgraph_node* 0x%x' % int(self.gdbval)
+if int(self.gdbval):
# symtab_node::name calls lang_hooks.decl_printable_name
# default implementation (lhd_decl_printable_name) is:
#return IDENTIFIER_POINTER (DECL_NAME (decl));
@@ -261,12 +261,12 @@ class DWDieRefPrinter:
self.gdbval = gdbval
def to_string (self):
-if long(self.gdbval) == 0:
+if int(self.gdbval) == 0:
return 'dw_die_ref 0x0'
-result = 'dw_die_ref 0x%x' % long(self.gdbval)
+result = 'dw_die_ref 0x%x' % int(self.gdbval)
result += ' %s' % self.gdbval['die_tag']
-if long(self.gdbval['die_parent']) != 0:
-result += ' parent=0x%x %s' % (long(self.gdbval['die_parent']),
+if int(self.gdbval['die_parent']) != 0:
+result += ' parent=0x%x %s' % (int(self.gdbval['die_parent']),
self.gdbval['die_parent']['die_tag'])
result += ''
@@ -279,13 +279,13 @@ class GimplePrinter:
self.gdbval = gdbval
def to_string (self):
-if long(self.gdbval) == 0:
+if int(self.gdbval) == 0:
return 'gimple 0x0'
val_gimple_code = self.gdbval['code']
val_gimple_code_name = gdb.parse_and_eval('gimple_code_name')
-val_code_name = val_gimple_code_name[long(val_gimple_code)]
+val_code_name = val_gimple_code_name[int(val_gimple_code)]
result = '%s 0x%x' % (val_code_name.string(),
- long(self.gdbval))
+ int(self.gdbval))
result += ''
return result
@@ -306,9 +306,9 @@ class BasicBlockPrinter:
self.gdbval = gdbval
def to_string (self):
-result = 'basic_block 0x
Re: [patch+7.9] compile: Filter out -fpreprocessed
On Tue, 03 Feb 2015 19:50:40 +0100, Doug Evans wrote: On Fri, Jan 16, 2015 at 2:42 PM, Jan Kratochvil jan.kratoch...@redhat.com wrote: [...] It is wrong that gcc puts -fpreprocessed into DW_AT_producer - I may post a gcc patch for it. Hi. I wasn't aware there are now rules for what can and cannot go in DW_AT_producer. DW_AT_producer has gone from being informational to having a formal spec (in the sense that something will break if, for example, a particular option is mentioned). Is this spec written down somewhere? [At least guidelines for what things may lead to breakage?] No. Do you have a suggestion where to put it? Should it be only a GNU extension or should it be even DWARF-standardized? Jan
[commit] [patch] DW_AT_producer: Ignore -fpreprocessed
On Sat, 17 Jan 2015 07:41:51 +0100, Jakub Jelinek wrote: gcc/ChangeLog * dwarf2out.c (gen_producer_string): Ignore also OPT_fpreprocessed. Ok for trunk, thanks. Checked in: 219797 Jan
[patch] DW_AT_producer: Ignore -fpreprocessed
Hi, I have provided a sufficient fix in GDB for the -fplugin=libcc1plugin feature: [patch+7.9] compile: Filter out -fpreprocessed https://sourceware.org/ml/gdb-patches/2015-01/msg00485.html But still I think -fpreprocessed is inappropriate for DW_AT_producer. Otherwise for an inferior built using ccache the string -fpreprocessed is put into DW_AT_producer and then GDB compilation with -fplugin=libcc1plugin breaks as the GDB-runtime-generated source is not already preprocessed. I have rebuilt GCC but I have not run the testsuite with this patch. Jan gcc/ChangeLog * dwarf2out.c (gen_producer_string): Ignore also OPT_fpreprocessed. Index: ./gcc/dwarf2out.c === --- ./gcc/dwarf2out.c (revision 219770) +++ ./gcc/dwarf2out.c (working copy) @@ -19624,6 +19624,7 @@ gen_producer_string (void) case OPT__sysroot_: case OPT_nostdinc: case OPT_nostdinc__: + case OPT_fpreprocessed: /* Ignore these. */ continue; default:
Re: [PATCH 5/5] add libcc1 [gcc-5/changes.html]
On Sun, 14 Sep 2014 17:07:05 +0200, Manuel López-Ibáñez wrote: What happened with this? I don't see any libcc1 in the gcc repository and this patch was never committed. It was discussed internally and the patches are going to be updated, rebased and later checked in. Thanks, Jan
Re: [PATCH 5/5] add libcc1 [gcc-5/changes.html]
On Tue, 05 Aug 2014 21:34:00 +0200, Tom Tromey wrote: Jeff == Jeff Law l...@redhat.com writes: Jeff Does this deserve a mention in the news file? I suppose so, I will get someone here to write it. Attached (based on Tom's PATCH 0/5 mail). Jan Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.2 diff -u -p -r1.2 changes.html --- htdocs/gcc-5/changes.html 30 Jul 2014 18:02:31 - 1.2 +++ htdocs/gcc-5/changes.html 8 Aug 2014 12:10:46 - @@ -20,7 +20,25 @@ !-- h3 id=adaAda/h3 -- !-- h3 id=c-familyC family/h3 -- -!-- h3 id=cC/h3-- + +h3 id=cC/h3 + ul +liGDB evaluation of a block of source code is now provided by new GCC +plugin.br / +For example: +pre + (gdb) compile code int i; for (i = 0; i 3; ++i) printf (#%d\n, i) + #0 + #1 + #2 +/pre +A user can compile a code snippet and it will be inserted into the inferior +and evaluated. Declarations needed by the snippet are supplied by GDB, and +there is a GDB--GCC interface so that the snippets can refer to local +variables in the current inferior frame. +/li + /ul + !-- h3 id=cxxC++/h3-- !-- h4 id=libstdcxxRuntime Library (libstdc++)/h4-- h3 id=fortranFortran/h3
ping^3: [patch] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407)
Hi, [patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407) http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html Message-ID: 20130514191244.ga12...@host2.jankratochvil.net Thanks, Jan
ping^2: [patch] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407)
Hi, [patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407) http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html Message-ID: 20130514191244.ga12...@host2.jankratochvil.net Thanks, Jan
Re: [GCC PR55056] Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL
On Fri, 14 Jun 2013 15:02:47 +0200, Thomas Schwinge wrote: On Sun, 3 Feb 2013 18:27:21 +0100, Jan Kratochvil jan.kratoch...@redhat.com wrote: gdb/testsuite/ 2013-02-02 Jan Kratochvil jan.kratoch...@redhat.com Workaround GCC PR debug/55056 and GDB PR server/15081. * gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef. (caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef. (caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef. * gdb.base/restore.exp: New variable opts. Test caller3, caller4 and caller5 for l1, l2 and l3. New prepare_for_testing. * gdb.base/store.c (wack_longest, wack_float, wack_double) (wack_doublest): Protect l and r by GCC_PR_55056 #ifdef. * gdb.base/store.exp: New variable opts. Test longest, float, double and doublest functions for l and r. New prepare_for_testing. * gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by GCC_PR_55056 #ifdef. Protect locar by GDB_PR_15081 #ifdef. * gdb.trace/unavailable.c: Likewise. * gdb.trace/collection.exp: New variable opts. Test reglocal_test_func for locf, locd and locar. New prepare_for_testing. (gdb_collect_locals_test): Increase list size to 43. * gdb.trace/unavailable.exp: Likewise. As far as I can tell, no consensus has yet been reached about the approach to fix this issue discussed in this thread. (I have not looked at the proposed patch in detail.) I have found now I posted the testsuite workaround for GDB http://sourceware.org/ml/gdb-patches/2013-01/msg00688.html but it has never been checked-in (neither in Fedora) which explains why you see PASS-FAIL (which I also see on Fedora 19). Jan
ping: [patch] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407)
Hi, [patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407) http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html Message-ID: 20130514191244.ga12...@host2.jankratochvil.net Thanks, Jan
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407)
Added its gcc/doc/ part. Previous pending post was:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00275.html
Message-ID: 20130506172221.ga21...@host2.jankratochvil.net
--
Hi,
since
[patch] x86_64: CFI unwinding stop in _start
http://sourceware.org/ml/libc-alpha/2012-03/msg00573.html
there is a regression reproducible with gold:
http://sourceware.org/bugzilla/show_bug.cgi?id=15407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57280 (GCC tracker)
as .eh_frame is created before the __EH_FRAME_BEGIN__ marker. Linking order:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
^^^ __EH_FRAME_BEGIN__ marker here
Therefore proposing to move the __EH_FRAME_BEGIN__ marker earlier:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin1.o
^^^ __EH_FRAME_BEGIN__ marker here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
It is questionable which all targets should this change affect. If find it
a needless + untestable change to split crtbegin.o for very every target.
I have split it for every glibc x86_64 target (I hope) even if the one uses
PT_GNU_EH_FRAME (for which the __EH_FRAME_BEGIN__ marker is not needed),
it does not hurt and it was easier (possible?) that way.
I have split it also for the non-Linux glibc i386 + x86_64 targets as AFAIK
they are also affected the same way by the glibc change.
I had to split also i386 despite the glibc change affects only x86_64. It was
needed for the case of --target=i686-pc-linux-gnu --enable-targets=all where:
gcc/config.gcc:
i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu |
i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu)
[...]
if test x$enable_targets = xall; then
tm_file=${tm_file} i386/x86-64.h
i386/gnu-user-common.h i386/gnu-user64.h i386/linux-common.h i386/linux64.h
Here the x86_64 *.h files get included even for the i386 target configuration
so it is no longer possible to make the spec change different for i386.
No regressions for Fedora 19 x86_64 GCC 4.9.0 20130504
and for gcc-4.8.0-3.fc19.{x86_64,i686}.
The x$enable_targets = xall case was tested on Debian 7.0 i386 with:
--enable-languages=c --without-cloog --disable-libquadmath
--enable-targets=all
It would be good to test also on some of the *BSD hosts, I will try some from
the GCC Compile Farm if this patch gets approved.
Thanks,
Jan
gcc/
2013-05-14 Jan Kratochvil jan.kratoch...@redhat.com
* config/i386/gnu-user-common.h (USE_CRT_BEGIN1)
(GNU_USER_TARGET_BEGIN1_SPEC, STARTFILE_SPEC): New.
* config/i386/linux-common.h (STARTFILE_SPEC): Use also
GNU_USER_TARGET_BEGIN1_SPEC.
* doc/fragments.texi (Target Fragment): Mention also crtbeginS1.o for
CRTSTUFF_T_CFLAGS_S.
* doc/tm.texi.in (Initialization): Add crtbegin1.o to the example.
Mention also crtbeginS1.o for crtstuff.c.
(Exception Region Output): Add USE_CRT_BEGIN1.
* doc/tm.texi: Regenerated.
libgcc/
2013-05-06 Jan Kratochvil jan.kratoch...@redhat.com
* Makefile.in (crtbegin1$(objext), crtbeginS1$(objext))
(crtbeginT1$(objext)): New.
* config.host (i[34567]86-*-linux*, i[34567]86-*-kfreebsd*-gnu)
(i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*)
(i[34567]86-*-kopensolaris*-gnu, x86_64-*-linux*)
(x86_64-*-kfreebsd*-gnu, x86_64-*-knetbsd*-gnu): Add crtbegin1.o,
crtbeginS1.o and crtbeginT1.o.
* crtstuff.c: New block for CRT_BEGIN1. Copy __EH_FRAME_BEGIN__ there
and also move it to the start of CRT_BEGIN block.
diff --git a/gcc/config/i386/gnu-user-common.h
b/gcc/config/i386/gnu-user-common.h
index e28483d..7848906 100644
--- a/gcc/config/i386/gnu-user-common.h
+++ b/gcc/config/i386/gnu-user-common.h
@@ -45,6 +45,14 @@ along with GCC; see the file COPYING3. If not see
#undef CC1_SPEC
#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC
+#undef USE_CRT_BEGIN1
+#define USE_CRT_BEGIN1
+#define GNU_USER_TARGET_BEGIN1_SPEC \
+ %{static:crtbeginT1.o%s;shared|pie:crtbeginS1.o%s;:crtbegin1.o%s}
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC GNU_USER_TARGET_BEGIN1_SPEC \
+ GNU_USER_TARGET_STARTFILE_SPEC
+
/* Similar to standard GNU userspace, but adding -ffast-math support. */
#define GNU_USER_TARGET_MATHFILE_SPEC \
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
index 1e8bf6b..a442bb1 100644
--- a/gcc/config/i386/linux
[patch] Support .eh_frame in crt1 x86_64 glibc (PR libc/15407)
Hi,
since
[patch] x86_64: CFI unwinding stop in _start
http://sourceware.org/ml/libc-alpha/2012-03/msg00573.html
there is a regression reproducible with gold:
http://sourceware.org/bugzilla/show_bug.cgi?id=15407
as .eh_frame is created before the __EH_FRAME_BEGIN__ marker. Linking order:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
^^^ __EH_FRAME_BEGIN__ marker here
Therefore proposing to move the __EH_FRAME_BEGIN__ marker earlier:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin1.o
^^^ __EH_FRAME_BEGIN__ marker here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
It is questionable which all targets should this change affect. If find it
a needless + untestable change to split crtbegin.o for very every target.
I have split it for every glibc x86_64 target (I hope) even if the one uses
PT_GNU_EH_FRAME (for which the __EH_FRAME_BEGIN__ marker is not needed),
it does not hurt and it was easier (possible?) that way.
I have split it also for the non-Linux glibc i386 + x86_64 targets as AFAIK
they are also affected the same way by the glibc change.
I had to split also i386 despite the glibc change affects only x86_64. It was
needed for the case of --target=i686-pc-linux-gnu --enable-targets=all where:
gcc/config.gcc:
i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu |
i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu)
[...]
if test x$enable_targets = xall; then
tm_file=${tm_file} i386/x86-64.h
i386/gnu-user-common.h i386/gnu-user64.h i386/linux-common.h i386/linux64.h
Here the x86_64 *.h files get included even for the i386 target configuration
so it is no longer possible to make the spec change different for i386.
No regressions for Fedora 19 x86_64 GCC 4.9.0 20130504
and for gcc-4.8.0-3.fc19.{x86_64,i686}.
The x$enable_targets = xall case was tested on Debian 7.0 i386 with:
--enable-languages=c --without-cloog --disable-libquadmath
--enable-targets=all
It would be good to test also on some of the *BSD hosts, I will try some from
the GCC Compile Farm if this patch gets approved.
Thanks,
Jan
gcc/
2013-05-06 Jan Kratochvil jan.kratoch...@redhat.com
* config/i386/gnu-user-common.h (USE_CRT_BEGIN1)
(GNU_USER_TARGET_BEGIN1_SPEC, STARTFILE_SPEC): New.
* config/i386/linux-common.h (STARTFILE_SPEC): Use also
GNU_USER_TARGET_BEGIN1_SPEC.
libgcc/
2013-05-06 Jan Kratochvil jan.kratoch...@redhat.com
* Makefile.in (crtbegin1$(objext), crtbeginS1$(objext))
(crtbeginT1$(objext)): New.
* config.host (i[34567]86-*-linux*, i[34567]86-*-kfreebsd*-gnu)
(i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*)
(i[34567]86-*-kopensolaris*-gnu, x86_64-*-linux*)
(x86_64-*-kfreebsd*-gnu, x86_64-*-knetbsd*-gnu): Add crtbegin1.o,
crtbeginS1.o and crtbeginT1.o.
* crtstuff.c: New block for CRT_BEGIN1. Copy __EH_FRAME_BEGIN__ there
and also move it to the start of CRT_BEGIN block.
diff --git a/gcc/config/i386/gnu-user-common.h
b/gcc/config/i386/gnu-user-common.h
index e28483d..7848906 100644
--- a/gcc/config/i386/gnu-user-common.h
+++ b/gcc/config/i386/gnu-user-common.h
@@ -45,6 +45,14 @@ along with GCC; see the file COPYING3. If not see
#undef CC1_SPEC
#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC
+#undef USE_CRT_BEGIN1
+#define USE_CRT_BEGIN1
+#define GNU_USER_TARGET_BEGIN1_SPEC \
+ %{static:crtbeginT1.o%s;shared|pie:crtbeginS1.o%s;:crtbegin1.o%s}
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC GNU_USER_TARGET_BEGIN1_SPEC \
+ GNU_USER_TARGET_STARTFILE_SPEC
+
/* Similar to standard GNU userspace, but adding -ffast-math support. */
#define GNU_USER_TARGET_MATHFILE_SPEC \
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
index 1e8bf6b..a442bb1 100644
--- a/gcc/config/i386/linux-common.h
+++ b/gcc/config/i386/linux-common.h
@@ -44,7 +44,8 @@ along with GCC; see the file COPYING3. If not see
#undef STARTFILE_SPEC
#define STARTFILE_SPEC \
- LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_BEGIN1_SPEC \
+ GNU_USER_TARGET_STARTFILE_SPEC, \
ANDROID_STARTFILE_SPEC)
#undef ENDFILE_SPEC
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 990cd49..5a8d834 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -953,6 +953,9 @@ ifeq ($(CUSTOM_CRTSTUFF),)
# Compile two additional files that are linked
Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL
Hi,
just forgot also about gdb.trace/unavailable.exp, equivalent to previous
gdb.trace/collection.exp workarounds.
Jan
gdb/testsuite/
2013-02-02 Jan Kratochvil jan.kratoch...@redhat.com
Workaround GCC PR debug/55056 and GDB PR server/15081.
* gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef.
(caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef.
(caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef.
* gdb.base/restore.exp: New variable opts. Test caller3, caller4 and
caller5 for l1, l2 and l3. New prepare_for_testing.
* gdb.base/store.c (wack_longest, wack_float, wack_double)
(wack_doublest): Protect l and r by GCC_PR_55056 #ifdef.
* gdb.base/store.exp: New variable opts. Test longest, float, double
and doublest functions for l and r. New prepare_for_testing.
* gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by
GCC_PR_55056 #ifdef. Protect locar by GDB_PR_15081 #ifdef.
* gdb.trace/unavailable.c: Likewise.
* gdb.trace/collection.exp: New variable opts. Test reglocal_test_func
for locf, locd and locar. New prepare_for_testing.
(gdb_collect_locals_test): Increase list size to 43.
* gdb.trace/unavailable.exp: Likewise.
diff --git a/gdb/testsuite/gdb.base/restore.c b/gdb/testsuite/gdb.base/restore.c
index 526be5f..a9b6d28 100644
--- a/gdb/testsuite/gdb.base/restore.c
+++ b/gdb/testsuite/gdb.base/restore.c
@@ -206,6 +206,10 @@ caller2 (void)
int
caller3 (void)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l1 = increment (0x7eeb); /* caller3 prologue */
register int l2 = increment (l1);
register int l3 = increment (l2);
@@ -222,7 +226,15 @@ caller3 (void)
int
caller4 (void)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l1 = increment (0x7eeb); /* caller4 prologue */
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l2 = increment (l1);
register int l3 = increment (l2);
register int l4 = increment (l3);
@@ -239,8 +251,20 @@ caller4 (void)
int
caller5 (void)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l1 = increment (0x7eeb); /* caller5 prologue */
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l2 = increment (l1);
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register int l3 = increment (l2);
register int l4 = increment (l3);
register int l5 = increment (l4);
diff --git a/gdb/testsuite/gdb.base/restore.exp
b/gdb/testsuite/gdb.base/restore.exp
index dbe01dc..a7fa91b 100644
--- a/gdb/testsuite/gdb.base/restore.exp
+++ b/gdb/testsuite/gdb.base/restore.exp
@@ -24,7 +24,37 @@
standard_testfile
set executable $testfile
-if { [prepare_for_testing $testfile.exp $executable $srcfile] } {
+set opts {debug}
+
+if { [prepare_for_testing $testfile.exp $executable $srcfile $opts] } {
+return -1
+}
+
+if {![runto_main]} {
+return -1
+}
+
+foreach caller { caller3 caller4 caller5 } { with_test_prefix $caller {
+gdb_breakpoint $caller
+gdb_continue_to_breakpoint $caller
+
+foreach l { l1 l2 l3 } { with_test_prefix $l {
+ set test info addr $l
+ gdb_test_multiple $test $test {
+ -re \r\nSymbol \$l\ is optimized out\\.\r\n$gdb_prompt $ {
+ lappend opts additional_flags=-DGCC_PR_55056
+ xfail $test (register variable has no location)
+ }
+ -re \r\nSymbol \$l\ is .*\r\n$gdb_prompt $ {
+ pass $test
+ }
+ }
+}}
+}}
+
+set executable ${testfile}opts
+
+if { [prepare_for_testing $testfile.exp $executable $srcfile $opts] } {
return -1
}
diff --git a/gdb/testsuite/gdb.base/store.c b/gdb/testsuite/gdb.base/store.c
index 545515d..3ac4a1a 100644
--- a/gdb/testsuite/gdb.base/store.c
+++ b/gdb/testsuite/gdb.base/store.c
@@ -98,6 +98,10 @@ wack_long (register long u, register long v)
long
wack_longest (register longest u, register longest v)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register longest l = u, r = v;
l = add_longest (l, r);
return l + r;
@@ -106,6 +110,10 @@ wack_longest (register longest u, register longest v)
float
wack_float (register float u, register float v)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
+ volatile
+#endif
register float l = u, r = v;
l = add_float (l, r);
return l + r;
@@ -114,6 +122,10 @@ wack_float (register float u, register float v)
double
wack_double (register double u, register double v)
{
+ /* volatile is a GCC PR debug/55056 workaround. */
+#ifdef GCC_PR_55056
Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote: Unless someone can shoot holes in this test approach, While the sum of *.o files sizes may make sense in some cases I would find more useful to measure it only for the final executables and after they have been processed by dwz. Besides dwz also .debug_* sections relocations have large size and all these relocations get removed in the final executable. Thanks, Jan
Re: stabs support in binutils, gcc, and gdb
On Mon, 14 Jan 2013 17:12:25 +0100, Doug Evans wrote: Not that I think it's a priori worth the effort to dig deeper, but for another datapoint, Redhat added an lza-compressed mini-dwarf-debug section. I'm not sure what it supports (if anything beyond making backtraces better). It can contain anything what separate debug info file may contain, incl. .debug_* sections. Access to those sections may be performance sub-optimal (decompressing blocks per seek request), unaware if usably or unusably slow. Jan
Re: gcc 4.7 libgo patch committed: Set libgo version number
Hello Ian, On Tue, 23 Oct 2012 06:55:01 +0200, Ian Lance Taylor wrote: PR 54918 points out that libgo is not using version numbers as it should. At present none of libgo in 4.6, 4.7 and mainline are compatible with each other. This patch to the 4.7 branch sets the version number for libgo there. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to 4.7 branch. it has regressed GDB testsuite: -PASS: gdb.go/handcall.exp: print add (1, 2) +FAIL: gdb.go/handcall.exp: print add (1, 2) GNU gdb (GDB) 7.5.50.20121022-cvs before: (gdb) print add (1, 2) $1 = 3 (gdb) ptype add type = int32 (int, int) (gdb) info line add Line 219 of ../../../libgo/runtime/cpuprof.c starts at address 0x755c0884 tick+52 and ends at 0x755c0898 tick+72. now: (gdb) print add (1, 2) Too few arguments in function call. (gdb) ptype add type = void (Profile *, uintptr *, int32) (gdb) info line add Line 212 of ../../../gcc47/libgo/runtime/cpuprof.c starts at address 0x755b05fe add and ends at 0x755b0609 add+11. Regards, Jan
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote: GDB folks, would it be hard to figure out that there is a single variant of the called function and trust the user that they are passing the right pointer value? It is a needless violation of C++ resolving rules. There are various easy way how to get it working (in .gdbinit or cc1-gdb.gdb define GDB function, define macro in GDB, use GDB python pretty printer instead (possibly even calling GCC inferior function) etc.). While I did not post such patch yet I would prefer to even forbid by default expressions like (gdb) print *0x1234567 and enforce (gdb) print *(int *)0x1234567 instead as the former syntax confuses people (as commonly seen on IRC), the same applies to calling functions without full debuginfo (they should require an explicit cast in GDB) etc. Regards, Jan
Re: Merge C++ conversion into trunk (0/6 - Overview)
Hi, On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote: On Wed, 15 Aug 2012, Jan Kratochvil wrote: It's not needless as the examples here show. gdb is about helping people debug their stuff, not about language lawyering. In such case there should be a GDB setting for it as at least from my opinion it complicates the debugging. Then there may be different opinions what should be the default. Thanks, Jan
Re: [patch] PR debug/53948
Hello Steven, On Wed, 18 Jul 2012 19:46:16 +0200, Steven Bosscher wrote: This is my proposed fix for PR53948. I can't speak for the GCC code but could it have a GCC testcase? Thanks, Jan
Re: [patch] PR debug/53948
On Wed, 18 Jul 2012 20:05:46 +0200, Steven Bosscher wrote:
I wouldn't know what to test for. Looking for a .loc marker seems a bit
fragile.
What is fragile on
// { dg-final { scan-assembler-times \\.loc\t1 3 0\\r\\n\t\[^.\] 6 } }
or something like that. Line numbers are constant for the testcase.
Thanks,
Jan
Re: [RFA] leb128.h: New file.
On Mon, 21 May 2012 02:30:58 +0200, Doug Evans wrote:
Ping.
On Thu, May 17, 2012 at 11:29 AM, Doug Evans d...@google.com wrote:
[...]
--- /dev/null 1 Jan 1970 00:00:00 -
+++ leb128.h 17 May 2012 18:23:29 -
[...]
+/* Get a definition for NULL. */
+#include stdio.h
I think stddef.h for NULL.
[...]
+static inline int
Return type should be size_t or ptrdiff_t. Likewise for other functions.
+read_uleb128 (const unsigned char *buf, const unsigned char *buf_end,
+ uint64_t *r)
+{
+ const unsigned char *p = buf;
+ unsigned int shift = 0;
+ uint64_t result = 0;
+ unsigned char byte;
+
+ while (1)
+ {
+ if (p = buf_end)
+ return 0;
+
+ byte = *p++;
+ result |= ((uint64_t) (byte 0x7f)) shift;
+ if ((byte 0x80) == 0)
+ break;
+ shift += 7;
+ }
+
+ *r = result;
+ return p - buf;
+}
[...]
Regards,
Jan
[patch] dwarf2out: Use DW_FORM_ref_udata (.debug -= 7.53%)
Hi,
this is a standalone patch to replace DW_FORM_ref4 by DW_FORM_ref_udata
(uleb128). It saves for libstdc++.so.debug: 5254792 - 4859136 = 7.53%
Tested with: -O2 -gdwarf-4 -fdebug-types-section
The references are already intra-CU ones, they are never relocated, they are
pre-computed by dwarf2out.c as plain numbers already. IIRC I got this idea
after reading Google Fission but it does not deal with intra-CU refs.
The change does not apply to CFI references, those are unchanged, generated by
different code of dwarf2out.c.
I had a draft patch to use DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref_udata and
DW_FORM_ref4 which should be slightly smaller than just DW_FORM_ref_udata.
But it produced larger files than just DW_FORM_ref_udata. Assuming it was due
to multiplied abbrev definitions. One would need to decide when if it is
worth to create a new smaller-sized abbrev but that seems too complicated for
such kind of optimization. There exist other project(s) in development for
DWARF optimizations as a post-processing tool, this patch is meant just as
a very simple way to reduce the (possibly intermediate) DWARF files.
It is incompatible with GNU binutils readelf, a pending simple fix is:
[patch] Fix readelf for DW_FORM_ref_udata
http://sourceware.org/ml/binutils/2011-10/msg00201.html
No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu
(4.7.0 20111002). No changes in readelf -w output on libstdc++.so.
My former DW_AT_sibling patch will be updated on top of this one:
Re: [patch#2] dwarf2out: Drop the size + performance overhead of
DW_AT_sibling
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01869.html
These two optimizations are not incremental to each other as both benefit
primarily from common DW_AT_sibling. That size decrease 3.49% will be less
after this patch; moreover when not all DW_AT_sibling attrs will be dropped.
Thanks,
Jan
gcc/
2011-10-21 Jan Kratochvil jan.kratoch...@redhat.com
* dwarf2out.c (DW_FORM_ref): Remove.
(size_of_die) dw_val_class_die_ref: Use size_of_uleb128 for
!AT_ref_external references.
(calc_die_sizes_change): New variable.
(calc_die_sizes): Permit die_offset incrementals. Set
CALC_DIE_SIZES_CHANGE accordingly.
(value_format) dw_val_class_die_ref: Return DW_FORM_ref_udata for
!AT_ref_external references.
(output_die) dw_val_class_die_ref: Use dw2_asm_output_data_uleb128
for !AT_ref_external references.
(output_unit_prep): New function, call calc_die_sizes repeatedly based
on CALC_DIE_SIZES_CHANGE.
(output_comp_unit, output_comdat_type_unit): Move some code to
output_unit_prep.
--- gcc/dwarf2out.c
+++ gcc/dwarf2out.c
@@ -226,7 +226,6 @@ static GTY(()) rtx current_unit_personality;
/* Data and reference forms for relocatable data. */
#define DW_FORM_data (DWARF_OFFSET_SIZE == 8 ? DW_FORM_data8 : DW_FORM_data4)
-#define DW_FORM_ref (DWARF_OFFSET_SIZE == 8 ? DW_FORM_ref8 : DW_FORM_ref4)
#ifndef DEBUG_FRAME_SECTION
#define DEBUG_FRAME_SECTION.debug_frame
@@ -7700,7 +7699,7 @@ size_of_die (dw_die_ref die)
size += DWARF_OFFSET_SIZE;
}
else
- size += DWARF_OFFSET_SIZE;
+ size += size_of_uleb128 (AT_ref (a)-die_offset);
break;
case dw_val_class_fde_ref:
size += DWARF_OFFSET_SIZE;
@@ -7735,6 +7734,10 @@ size_of_die (dw_die_ref die)
return size;
}
+/* Has calc_die_sizes changed any DIE_OFFSET? */
+
+static bool calc_die_sizes_change;
+
/* Size the debugging information associated with a given DIE. Visits the
DIE's children recursively. Updates the global variable next_die_offset, on
each time through. Uses the current value of next_die_offset to update the
@@ -7745,9 +7748,12 @@ calc_die_sizes (dw_die_ref die)
{
dw_die_ref c;
- gcc_assert (die-die_offset == 0
- || (unsigned long int) die-die_offset == next_die_offset);
- die-die_offset = next_die_offset;
+ gcc_assert ((unsigned long int) die-die_offset = next_die_offset);
+ if ((unsigned long int) die-die_offset != next_die_offset)
+{
+ die-die_offset = next_die_offset;
+ calc_die_sizes_change = true;
+}
next_die_offset += size_of_die (die);
FOR_EACH_CHILD (die, c, calc_die_sizes (c));
@@ -8018,7 +8024,7 @@ value_format (dw_attr_ref a)
if (AT_ref_external (a))
return use_debug_types ? DW_FORM_ref_sig8 : DW_FORM_ref_addr;
else
- return DW_FORM_ref;
+ return DW_FORM_ref_udata;
case dw_val_class_fde_ref:
return DW_FORM_data;
case dw_val_class_lbl_id:
@@ -8397,8 +8403,7 @@ output_die (dw_die_ref die)
else
{
gcc_assert (AT_ref (a)-die_offset);
- dw2_asm_output_data (DWARF_OFFSET_SIZE, AT_ref (a)-die_offset,
- %s, name);
+ dw2_asm_output_data_uleb128 (AT_ref (a)-die_offset
Re: [patch] dwarf2out: Use DW_FORM_ref_udata (.debug -= 7.53%)
On Fri, 21 Oct 2011 20:01:29 +0200, Jan Kratochvil wrote:
No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu
(4.7.0 20111002).
A typo, only tested for x86_64-fedora16pre-linux-gnu, sorry.
Jan
Re: [patch] dwarf2out: Use DW_FORM_ref_udata (.debug -= 7.53%)
On Fri, 21 Oct 2011 21:11:16 +0200, Jakub Jelinek wrote:
Well, you calculate the sizes multiple times anyway, so I don't see why you
during the size calculations you couldn't start with DW_FORM_ref_udata
as first guess and compute on the side also total sizes of those
DW_FORM_ref_udata bytes and use that number plus the guessed length
of the whole CU to decide if replacing all DW_FORM_ref_udata with
DW_FORM_ref{1,2,4} wouldn't be beneficial.
The optimal sizes are:
value less than 1 8: DW_FORM_ref1
value less than 1 16: DW_FORM_ref2
value less than 1 21: DW_FORM_ref_udata
value less than 1 32: DW_FORM_ref4
One would have to decide each size specifically if it isn't worth to use the
larger size for the few instances. It could be done, just the gain is not
expected (not measured) big against DW_FORM_ref_udata. The currently
suboptimal ranges are:
(1 7) = value (1 8)
(1 14) = value (1 16)
(1 28) = value
This suboptimal loss is at most 9316 bytes = 0.177% of .debug size but it will
be less as I do not calculate here with the abbrevs multiplication at all:
readelf -wi libstdc++.so|perl -nle 'next if
!/^.*(0x[0-9a-f]+).*$/;$x=eval $1;$b++ if
(17)=$x$x(18)||(114)=$x$x(116)||(128)=$x;END{print $b;}'
9316
IMHO it is not worth it.
Also this problem is already present there. The following code may enlarge the
output in specific cases due to duplication of the abbrev definitions:
/* If the string is shorter or equal to the size of the reference, it is
always better to put it inline. */
^^ = not always
if (len = DWARF_OFFSET_SIZE || node-refcount == 0)
return node-form = DW_FORM_string;
This patch has a size regression for DIE_OFFSETs larger than 1 28 = 256MB
when DW_FORM_ref_udata becomes 5 bytes while DW_FORM_ref4 was 4 bytes.
Still I do not think it needs to care about optimal output for a single CU of
size larger than 256MB.
+ /* The DIE sizes can increase, due to DW_FORM_ref_udata size increase
+ dependent on increases of other DIE_OFFSETs. */
+ do
+{
+ /* Initialize the beginning DIE offset - and calculate
sizes/offsets. */
+ next_die_offset = init_die_offset;
+ calc_die_sizes_change = false;
+ calc_die_sizes (die);
+}
+ while (calc_die_sizes_change);
loop guaranteed to terminate? If the CU is either only growing or only
shrinking then it hopefully should, but it would be nice to assert that.
For references to DIEs with lower offsets you start with a roughly correct
guess, for references to DIEs with higher offsets you start with 0 and then
just keep growing?
Yes. The initial DIE_OFFSETs are 0, therefore their sizeof(uleb128) is 1.
As I assume
VAL1 = VAL2 implicates sizeof (uleb128 (VAL1)) = sizeof (uleb128
(VAL2))
there must be valid on each calc_die_sizes call the updated assertion:
gcc_assert ((unsigned long int) die-die_offset = next_die_offset);
I do not see anything could shrink anywhere.
Thanks,
Jan
[patch] dwarf2out crash: missing GTY? (PR 50806)
Hi,
with custom patched dwarf2out.c I got a crash on memory mangled by the garbage
collector. With patched GTY there the crash no longer happened - but I do not
have a reproducer anymore, sorry if it is a bogus patch.
The memory corrupted later was initially allocated and stored into
mem_loc_result-dw_loc_oprnd1.v.val_loc. I do not think there is any other
reference to it than that field with no GTY.
GIT 33e7b55c2549d655d88ec64c06c51912d0d07527
gcc (GCC) 4.7.0 20111002 (experimental)
11900 mem_loc_result-dw_loc_oprnd1.v.val_loc = op0;
(gdb) bt
#0 mem_loc_descriptor (rtl=, mode=SImode, mem_mode=VOIDmode,
initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:11900
#1 in loc_descriptor (rtl=, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12790
#2 in loc_descriptor (rtl=, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12614
#3 in dw_loc_list_1 (loc=, varloc=, want_address=2,
initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12889
#4 in dw_loc_list (loc_list=, decl=, want_address=2) at gcc/dwarf2out.c:13145
#5 in loc_list_from_tree (loc=, want_address=2) at gcc/dwarf2out.c:13538
#6 in add_location_or_const_value_attribute (die=, decl=, cache_p=0 '\000',
attr=DW_AT_location) at gcc/dwarf2out.c:15048
#7 in gen_formal_parameter_die (node=, origin=0x0, emit_name_p=1 '\001',
context_die=) at gcc/dwarf2out.c:16804
#8 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19632
#9 in gen_subprogram_die (decl=, context_die=) at gcc/dwarf2out.c:17560
#10 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19545
#11 in dwarf2out_decl (decl=) at gcc/dwarf2out.c:19919
#12 in dwarf2out_function_decl (decl=) at gcc/dwarf2out.c:19927
#13 in rest_of_handle_final () at gcc/final.c:4252
#14 in execute_one_pass (pass=0x4dbe120) at gcc/passes.c:2064
#15 in execute_pass_list (pass=0x4dbe120) at gcc/passes.c:2119
#16 in execute_pass_list (pass=0x4dbef00) at gcc/passes.c:2120
#17 in execute_pass_list (pass=0x4dbeea0) at gcc/passes.c:2120
#18 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420
#19 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803
#20 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862
#21 in cgraph_optimize () at gcc/cgraphunit.c:2133
#22 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310
#23 in c_write_global_declarations () at gcc/c-decl.c:9936
#24 in compile_file () at gcc/toplev.c:581
#25 in do_compile () at gcc/toplev.c:1925
#26 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001
#27 in main (argc=101, argv=) at gcc/main.c:36
It was later freed (watchpoint hit) by:
(gdb) bt
#0 __memset_sse2 () at ../sysdeps/x86_64/memset.S:333
#1 in poison_pages () at gcc/ggc-page.c:1845
#2 in ggc_collect () at gcc/ggc-page.c:1938
#3 in execute_todo (flags=2) at gcc/passes.c:1763
#4 in execute_one_pass (pass=0x4dbce80) at gcc/passes.c:2087
#5 in execute_pass_list (pass=0x4dbce80) at gcc/passes.c:2119
#6 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420
#7 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803
#8 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862
#9 in cgraph_optimize () at gcc/cgraphunit.c:2133
#10 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310
#11 in c_write_global_declarations () at gcc/c-decl.c:9936
#12 in compile_file () at gcc/toplev.c:581
#13 in do_compile () at gcc/toplev.c:1925
#14 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001
#15 in main (argc=101, argv=) at gcc/main.c:36
And later it crashed on the mangled memory.
OK to check it in? No regression testing done.
Thanks,
Jan
gcc/
2011-10-20 Jan Kratochvil jan.kratoch...@redhat.com
* dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr;
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1211,7 +1210,7 @@ typedef struct GTY(()) dw_loc_list_struct {
char *ll_symbol; /* Label for beginning of location list.
Only on head of list */
const char *section; /* Section this loclist is relative to */
- dw_loc_descr_ref expr;
+ dw_loc_descr_ref GTY(()) expr;
hashval_t hash;
/* True if all addresses in this and subsequent lists are known to be
resolved. */
Re: [patch#2] dwarf2out: Drop the size + performance overhead of DW_AT_sibling
On Tue, 18 Oct 2011 10:38:23 +0200, Jakub Jelinek wrote: On Tue, Oct 18, 2011 at 10:28:09AM +0200, Jan Kratochvil wrote: 2011-10-12 Jan Kratochvil jan.kratoch...@redhat.com Stop producing DW_AT_sibling without -gstrict-dwarf. * dwarf2out.c (dwarf2out_finish): Remove calls of add_sibling_attributes if !DWARF_STRICT. Extend the comment with reason. This is ok for trunk. FYI this patch has not yet been checked in, it has negative performance effect on the systemtap DWARF consumer. http://sourceware.org/ml/archer/2011-q4/msg4.html I will post a patch removing only very short DW_AT_sibling skips later. Thanks, Jan
Re: [patch] dwarf2out crash: missing GTY? (PR 50806)
On Fri, 21 Oct 2011 05:37:09 +0200, Laurynas Biveinis wrote: This patch is a no-op, as already pointed out. If this comes up again, I'd set a conditional breakpoint on ggc_set_mark if (arg == struct dw_loc_list_struct with the field that gets collected) and try to find out why the field does not get marked. Thanks all for the review, I see I do not know the GC. I thought the bug is so obvious... I did not make a snapshot of the tree in that crashing state. Therefore I cannot say anything useful about the crash anymore. Thanks, Jan
[patch#2] dwarf2out: Drop the size + performance overhead of DW_AT_sibling
On Tue, 18 Oct 2011 09:24:08 +0200, Tristan Gingold wrote:
What is wrong with my suggestion of adding a command line option to keep the
siblings ? This option could be removed in a few years if nobody complained
about sibling removal.
I find an extra option just a pollution of doc and everything by an option
which will never get used. Wouldn't it be enough to disable it by
-gstrict-dwarf? While currently the -gstrict-dwarf meaning is different
I believe the purpose is correct - to be more backward compatible.
Thanks,
Jan
gcc/
2011-10-12 Jan Kratochvil jan.kratoch...@redhat.com
Stop producing DW_AT_sibling without -gstrict-dwarf.
* dwarf2out.c (dwarf2out_finish): Remove calls of
add_sibling_attributes if !DWARF_STRICT. Extend the comment with
reason.
--- gcc/dwarf2out.c (revision 180121)
+++ gcc/dwarf2out.c (working copy)
@@ -22496,13 +22496,17 @@ dwarf2out_finish (const char *filename)
prune_unused_types ();
}
- /* Traverse the DIE's and add add sibling attributes to those DIE's
- that have children. */
- add_sibling_attributes (comp_unit_die ());
- for (node = limbo_die_list; node; node = node-next)
-add_sibling_attributes (node-die);
- for (ctnode = comdat_type_list; ctnode != NULL; ctnode = ctnode-next)
-add_sibling_attributes (ctnode-root_die);
+ if (dwarf_strict)
+{
+ /* Traverse the DIE's and add add sibling attributes to those DIE's that
+have children. It is produced only for compatibility reasons as it is
+both a size and consumer performance hit. */
+ add_sibling_attributes (comp_unit_die ());
+ for (node = limbo_die_list; node; node = node-next)
+ add_sibling_attributes (node-die);
+ for (ctnode = comdat_type_list; ctnode != NULL; ctnode = ctnode-next)
+ add_sibling_attributes (ctnode-root_die);
+}
/* Output a terminator label for the .text section. */
switch_to_section (text_section);
Re: [patch] dwarf2out: Drop the size + performance overhead of DW_AT_sibling
On Wed, 12 Oct 2011 16:18:07 +0200, Jan Kratochvil wrote: On Wed, 12 Oct 2011 16:07:24 +0200, Tristan Gingold wrote: I fear that this may degrade performance of other debuggers. What about adding a command line option ? I can test idb, I do not find the difference measurable. Dropping DW_AT_sibling is 0.25% performance _improvement_ but I guess it is just less than the measurement error. libstdc++ built with gcc -gdwarf-2 as with gcc -gdwarf-4 -fdebug-types-section it crashes. i7-920 x86_64 used for testing: Intel(R) Debugger for applications running on Intel(R) 64, Version 12.1, Build [76.472.14] with DW_AT_sibling real2m34.206s 2m31.822s 2m31.709s 2m32.316s avg = 152.51325 seconds patched GCC without DW_AT_sibling real2m32.528s 2m30.524s 2m33.767s 2m31.719s avg = 152.1345 seconds I do not see a point in keeping DW_AT_sibling there. Regards, Jan
[patch] dwarf2out: Drop the size + performance overhead of DW_AT_sibling
Hi,
dropping the optional DWARF attribute DW_AT_sibling has only advantages and no
disadvantages:
For files with .gdb_index GDB initial scan does not use DW_AT_sibling at all.
For files without .gdb_index GDB initial scan has 1.79% time _improvement_.
For .debug files it brings 3.49% size decrease (7.84% for rpm compressed files).
I guess DW_AT_sibling had real performance gains on CPUs with 1x (=no) clock
multipliers. Nowadays mostly only the data size transferred over FSB matters.
I do not think there would be any DWARF consumers compatibility problems as
DW_AT_sibling has always been optional but I admit I have tested only GDB.
clean is FSF GCC+GDB, ns is FSF GCC with the patch applied.
gdbindex -readnow 100x warm:
clean:
56.975 57.161 57.738 58.243 57.529249 seconds
ns:
57.799 58.008 58.202 58.473 58.1204993 seconds
+1.03% = performance decrease but it should be 0%, it is a measurement error
gdbindex -readnow 20x warm(gdb) cold(data):
clean:
57.989
ns:
58.538
+0.95% = performance decrease but it should be 0%, it is a measurement error
200x warm:
clean:
14.393 14.414 14.587 14.496 14.4724998 seconds
ns:
14.202 14.160 14.174 14.318 14.2134998 seconds
-1.79% = performance improvement of non-gdbindex scan
(dwarf2_build_psymtabs_hard)
gdbindex .debug:
clean = 5589272 bytes
ns = 5394120 bytes
-3.49% = size improvement
gdbindex .debug.xz9:
clean = 1158696 bytes
ns = 1067900 bytes
-7.84% = size improvement
.debug_info + .debug_types:
clean = 0x1a11a0+0x08f389 bytes
ns = 0x184205+0x0833b0 bytes
-7.31% = size improvement
Intel i7-920 CPU and only libstdc++ from GCC 4.7.0 20111002 and `-O2 -gdwarf-4
-fdebug-types-section' were used for the benchmark. GCC 4.7.0 20111002
--enable-languages=c++ was used for `make check' regression testing.
Thanks,
Jan
gcc/
2011-10-12 Jan Kratochvil jan.kratoch...@redhat.com
Stop producing DW_AT_sibling.
* dwarf2out.c (add_sibling_attributes): Remove the declaration.
(add_sibling_attributes): Remove the function.
(dwarf2out_finish): Remove calls of add_sibling_attributes.
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3316,7 +3316,6 @@ static int htab_cu_eq (const void *, const void *);
static void htab_cu_del (void *);
static int check_duplicate_cu (dw_die_ref, htab_t, unsigned *);
static void record_comdat_symbol_number (dw_die_ref, htab_t, unsigned);
-static void add_sibling_attributes (dw_die_ref);
static void build_abbrev_table (dw_die_ref);
static void output_location_lists (dw_die_ref);
static int constant_size (unsigned HOST_WIDE_INT);
@@ -7482,24 +7481,6 @@ copy_decls_for_unworthy_types (dw_die_ref unit)
unmark_dies (unit);
}
-/* Traverse the DIE and add a sibling attribute if it may have the
- effect of speeding up access to siblings. To save some space,
- avoid generating sibling attributes for DIE's without children. */
-
-static void
-add_sibling_attributes (dw_die_ref die)
-{
- dw_die_ref c;
-
- if (! die-die_child)
-return;
-
- if (die-die_parent die != die-die_parent-die_child)
-add_AT_die_ref (die, DW_AT_sibling, die-die_sib);
-
- FOR_EACH_CHILD (die, c, add_sibling_attributes (c));
-}
-
/* Output all location lists for the DIE and its children. */
static void
@@ -22496,14 +22477,6 @@ dwarf2out_finish (const char *filename)
prune_unused_types ();
}
- /* Traverse the DIE's and add add sibling attributes to those DIE's
- that have children. */
- add_sibling_attributes (comp_unit_die ());
- for (node = limbo_die_list; node; node = node-next)
-add_sibling_attributes (node-die);
- for (ctnode = comdat_type_list; ctnode != NULL; ctnode = ctnode-next)
-add_sibling_attributes (ctnode-root_die);
-
/* Output a terminator label for the .text section. */
switch_to_section (text_section);
targetm.asm_out.internal_label (asm_out_file, TEXT_END_LABEL, 0);
Re: [patch] dwarf2out: Drop the size + performance overhead of DW_AT_sibling
On Wed, 12 Oct 2011 16:07:24 +0200, Tristan Gingold wrote: I fear that this may degrade performance of other debuggers. What about adding a command line option ? I can test idb, there aren't so many DWARF debuggers out there I think. If the default is removed DW_AT_sibling a new options may make sense as some compatibility safeguard. Thanks, Jan
-fdebug-types-section unidentifiable anonymous struct (PR debug/49750)
Hi all and Cary,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49750
It is a part of former Bug (FIXED):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510
currently -fdebug-types-section regresses GDB testsuite for:
FAIL: gdb.cp/anon-struct.exp: print type of X::t2::t2
FAIL: gdb.cp/member-ptr.exp: *
Describing `gdb.cp/anon-struct.exp' which is addressed also by Tom Tromey's
Bug above. Unaware if it fixes also gdb.cp/member-ptr.exp, I hope so.
There is no way to find out where the t2 method (constructor) belongs from
DIE 77 (it belongs to X::t2, making the constructor name X::t2::t2()).
With posted FSF GDB HEAD fix (fixing another unrelated issue):
[patch] Fix printed anonymous struct name
http://sourceware.org/ml/gdb-patches/2011-09/msg00483.html
I think it would be enough to just put proper declarations around the t2
method DIE, at least it works for me with the GDB patch above. But maybe
a better DWARF solution exists.
Thanks,
Jan
Attaching anonstruct4b.s patched by hand as the diff below suggests:
echo 'int main(){}'|g++ -g -c -o anonstructmain4.o -Wall -x c++ -;g++ -o
anonstruct4b anonstructmain4.o anonstruct4b.s -Wall
./gdb -q -nx -ex 'set language c++' -ex ptype X::t2::t2 -ex q ~/t/anonstruct4b
-There is no field named t2
-
+type = void (X::t2 * const)
1: Abbrev Number: 18 (DW_TAG_namespace)
DW_AT_name: X
2: Abbrev Number: 19 (DW_TAG_typedef)
DW_AT_name: t2
DW_AT_type: signature: 9d52f6834a49e845
2: Abbrev Number: 20 (DW_TAG_variable)
DW_AT_name: v
DW_AT_linkage_name: (indirect string, offset: ): _ZN1X1vE
DW_AT_type:
DW_AT_external: 1
DW_AT_declaration : 1
- 1: Abbrev Number: 21 (DW_TAG_structure_type)
- DW_AT_declaration : 1
+ 2: Abbrev Number: 21 (DW_TAG_structure_type)
+ DW_AT_declaration : 1
+ DW_AT_MIPS_linkage_name: (indirect string, offset: ): N1X2t2E
- 2: Abbrev Number: 22 (DW_TAG_subprogram)
+ 3: Abbrev Number: 22 (DW_TAG_subprogram)
DW_AT_name: t2
DW_AT_artificial : 1
DW_AT_declaration : 1
DW_AT_object_pointer:
.file anonstruct.C
.text
.Ltext0:
.weak _ZN1CC1Ev
.set_ZN1CC1Ev,_ZN1CC2Ev
.section.text._ZN1CC2Ev,axG,@progbits,_ZN1CC5Ev,comdat
.align 2
.weak _ZN1CC2Ev
.type _ZN1CC2Ev, @function
_ZN1CC2Ev:
.LFB1:
.file 1 anonstruct.C
# anonstruct.C:1
.loc 1 1 0
.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (fallthru)
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
# anonstruct.C:1
.loc 1 1 0
popq%rbp
.cfi_def_cfa 7, 8
# SUCC: EXIT [100.0%]
ret
.cfi_endproc
.LFE1:
.size _ZN1CC2Ev, .-_ZN1CC2Ev
.set_ZN1X2t2C1Ev,_ZN1X2t2C2Ev
.text
.align 2
.type _ZN1X2t2C2Ev, @function
_ZN1X2t2C2Ev:
.LFB4:
# anonstruct.C:6
.loc 1 6 0
.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (fallthru)
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
movq%rdi, -8(%rbp)
.LBB2:
# anonstruct.C:6
.loc 1 6 0
movq-8(%rbp), %rax
movq%rax, %rdi
call_ZN1CC1Ev
.LBE2:
leave
.cfi_def_cfa 7, 8
# SUCC: EXIT [100.0%]
ret
.cfi_endproc
.LFE4:
.size _ZN1X2t2C2Ev, .-_ZN1X2t2C2Ev
.globl _ZN1X1vE
.bss
.type _ZN1X1vE, @object
.size _ZN1X1vE, 1
_ZN1X1vE:
.zero 1
.text
.type _Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB6:
# anonstruct.C:9
.loc 1 9 0
.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (fallthru)
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
movl%edi, -4(%rbp)
movl%esi, -8(%rbp)
# anonstruct.C:9
.loc 1 9 0
cmpl$1, -4(%rbp)
# SUCC: 3 (fallthru) 5
jne .L3
# BLOCK 3 seq:1
# PRED: 2 (fallthru)
# anonstruct.C:9
.loc 1 9 0 is_stmt 0 discriminator 1
cmpl$65535, -8(%rbp)
# SUCC: 4 (fallthru) 5
jne .L3
# BLOCK 4 seq:2
# PRED: 3 (fallthru)
# anonstruct.C:8
.loc 1 8 0 is_stmt 1
movl$_ZN1X1vE, %edi
# SUCC: 5 (fallthru)
call_ZN1X2t2C1Ev
# BLOCK 5 seq:3
# PRED: 4 (fallthru) 2 3
.L3:
# anonstruct.C:9
.loc 1 9 0
leave
.cfi_def_cfa 7, 8
# SUCC: EXIT [100.0%]
ret
.cfi_endproc
.LFE6:
.size
Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)
On Fri, 23 Sep 2011 02:21:44 +0200, Cary Coutant wrote: * .debug_pubtypes - Public types for use in building the .gdb_index section at link time. This section will have an extended format to allow it to represent both types in the .debug_dwo_info section and type units in .debug_types. ^^^ = .dwo_info , maybe both .debug_info and .dwo_info * .dwo_abbrev - Defines the abbreviation codes used by the .debug_dwo_info section. ^^^ = .dwo_info I find this .dwo_* setup is great for rapid development rebuilds but it should remain optional as the currently used DWARF final separate .debug info file is smaller than all the .dwo files together. In the case of the final linked .debug builds (rpm/deb/...) one does not consider the build speed as important. It probably does not make sense to merge + convert .dwo files back to a single .debug file for the rpm/deb/... build performance reasons. Thanks, Jan
ping: [patch] libiberty/cp-demangle.c: Fix CP_DEMANGLE_DEBUG SIGSEGV
ping: On Tue, 28 Jun 2011 22:15:04 +0200, Jan Kratochvil wrote: Hi, a mechanical patch which fixes during #define CP_DEMANGLE_DEBUG make check - /bin/sh: line 1: 9179 Segmentation fault ./test-demangle ./demangle-expected which also fixes confusing output for _Z1hI1AIiEdEDTcldtfp_1gIT0_EEET_S2_ binary operator arguments binary operator operator . binary operator arguments ???--- template name 'g' template argument list template parameter 1 argument list Thanks, Jan libiberty/ 2011-06-28 Jan Kratochvil jan.kratoch...@redhat.com * cp-demangle.c (d_dump): Add (zero-based) to DEMANGLE_COMPONENT_TEMPLATE_PARAM. Implement DEMANGLE_COMPONENT_FUNCTION_PARAM, DEMANGLE_COMPONENT_VECTOR_TYPE, DEMANGLE_COMPONENT_NUMBER, DEMANGLE_COMPONENT_GLOBAL_CONSTRUCTORS, DEMANGLE_COMPONENT_GLOBAL_DESTRUCTORS, DEMANGLE_COMPONENT_LAMBDA, DEMANGLE_COMPONENT_DEFAULT_ARG and DEMANGLE_COMPONENT_UNNAMED_TYPE. Print ??? %d on unknown dc-type. --- a/libiberty/cp-demangle.c +++ b/libiberty/cp-demangle.c @@ -506,7 +507,10 @@ d_dump (struct demangle_component *dc, int indent) printf (name '%.*s'\n, dc-u.s_name.len, dc-u.s_name.s); return; case DEMANGLE_COMPONENT_TEMPLATE_PARAM: - printf (template parameter %ld\n, dc-u.s_number.number); + printf (template parameter %ld (zero-based)\n, dc-u.s_number.number); + return; +case DEMANGLE_COMPONENT_FUNCTION_PARAM: + printf (function parameter %ld (zero-based)\n, dc-u.s_number.number); return; case DEMANGLE_COMPONENT_CTOR: printf (constructor %d\n, (int) dc-u.s_ctor.kind); @@ -633,6 +637,9 @@ d_dump (struct demangle_component *dc, int indent) case DEMANGLE_COMPONENT_FIXED_TYPE: printf (fixed-point type\n); break; +case DEMANGLE_COMPONENT_VECTOR_TYPE: + printf (vector type\n); + break; case DEMANGLE_COMPONENT_ARGLIST: printf (argument list\n); break; @@ -675,12 +682,35 @@ d_dump (struct demangle_component *dc, int indent) case DEMANGLE_COMPONENT_CHARACTER: printf (character '%c'\n, dc-u.s_character.character); return; +case DEMANGLE_COMPONENT_NUMBER: + printf (number %ld\n, dc-u.s_number.number); + return; case DEMANGLE_COMPONENT_DECLTYPE: printf (decltype\n); break; +case DEMANGLE_COMPONENT_GLOBAL_CONSTRUCTORS: + printf (global constructors keyed to name\n); + break; +case DEMANGLE_COMPONENT_GLOBAL_DESTRUCTORS: + printf (global destructors keyed to name\n); + break; +case DEMANGLE_COMPONENT_LAMBDA: + printf (lambda %d (zero-based)\n, dc-u.s_unary_num.num); + d_dump (dc-u.s_unary_num.sub, indent + 2); + return; +case DEMANGLE_COMPONENT_DEFAULT_ARG: + printf (default argument %d (zero-based)\n, dc-u.s_unary_num.num); + d_dump (dc-u.s_unary_num.sub, indent + 2); + return; +case DEMANGLE_COMPONENT_UNNAMED_TYPE: + printf (unnamed type %ld\n, dc-u.s_number.number); + return; case DEMANGLE_COMPONENT_PACK_EXPANSION: printf (pack expansion\n); break; +default: + printf (??? %d\n, dc-type); + break; } d_dump (d_left (dc), indent + 2);
Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)
On Fri, 01 Jul 2011 18:27:36 +0200, Jason Merrill wrote: OK. Checked in: http://gcc.gnu.org/viewcvs?view=revisionrevision=175761 No regressions on gcc-4.6.1-1.fc15.x86_64 (it is not trunk but hopefully similar enough). Thanks, Jan
Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)
On Thu, 30 Jun 2011 00:27:31 +0200, Jason Merrill wrote:
The earlier output was correct. We just don't want to print g(int,
double).
OK, understood now. It got more clear with the new testcase:
_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv
decltype (((long)(5))+((q(short))(6))) tlong()
-
decltype (((long)(5))+(q(6))) tlong()
OK to check it in if the regression testing underway is OK?
Thanks,
Jan
libiberty/
2011-06-30 Jan Kratochvil jan.kratoch...@redhat.com
* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '' unary operator. Keep also already processed
variant without the argument list. Suppress argument list types for
function call used in an expression.
* testsuite/demangle-expected: Fix excessive argument list types in
`test for typed function in decltype'. New testcase for no argument
list types printed. 3 new testcases for function references by the
'' unary operator..
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4139,7 +4169,46 @@ d_print_comp (struct d_print_info *dpi, int options,
return;
case DEMANGLE_COMPONENT_UNARY:
- if (d_left (dc)-type != DEMANGLE_COMPONENT_CAST)
+ if (d_left (dc)-type == DEMANGLE_COMPONENT_OPERATOR
+ d_left (dc)-u.s_operator.op-len == 1
+ d_left (dc)-u.s_operator.op-name[0] == ''
+ d_right (dc)-type == DEMANGLE_COMPONENT_TYPED_NAME
+ d_left (d_right (dc))-type == DEMANGLE_COMPONENT_QUAL_NAME
+ d_right (d_right (dc))-type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+ {
+ /* Address of a function (therefore in an expression context) must
+have its argument list suppressed.
+
+unary operator ... dc
+ operator ... d_left (dc)
+ typed name ... d_right (dc)
+qualified name ... d_left (d_right (dc))
+ names
+function type ... d_right (d_right (dc))
+ argument list
+arguments */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_left (d_right (dc)));
+ return;
+ }
+ else if (d_left (dc)-type == DEMANGLE_COMPONENT_OPERATOR
+ d_left (dc)-u.s_operator.op-len == 1
+ d_left (dc)-u.s_operator.op-name[0] == ''
+ d_right (dc)-type == DEMANGLE_COMPONENT_QUAL_NAME)
+ {
+ /* Keep also already processed variant without the argument list.
+
+unary operator ... dc
+ operator ... d_left (dc)
+ qualified name ... d_right (dc)
+names */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_right (dc));
+ return;
+ }
+ else if (d_left (dc)-type != DEMANGLE_COMPONENT_CAST)
d_print_expr_op (dpi, options, d_left (dc));
else
{
@@ -4165,7 +4234,21 @@ d_print_comp (struct d_print_info *dpi, int options,
d_left (dc)-u.s_operator.op-name[0] == '')
d_append_char (dpi, '(');
- d_print_subexpr (dpi, options, d_left (d_right (dc)));
+ if (strcmp (d_left (dc)-u.s_operator.op-code, cl) == 0
+ d_left (d_right (dc))-type == DEMANGLE_COMPONENT_TYPED_NAME)
+ {
+ /* Function call used in an expression should not have printed types
+of the function arguments. Values of the function arguments still
+get printed below. */
+
+ const struct demangle_component *func = d_left (d_right (dc));
+
+ if (d_right (func)-type != DEMANGLE_COMPONENT_FUNCTION_TYPE)
+ d_print_error (dpi);
+ d_print_subexpr (dpi, options, d_left (func));
+ }
+ else
+ d_print_subexpr (dpi, options, d_left (d_right (dc)));
if (strcmp (d_left (dc)-u.s_operator.op-code, ix) == 0)
{
d_append_char (dpi, '[');
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3920,7 +3920,11 @@ decltype (({parm#1}.(gdouble))()) hAint,
double(Aint, double)
# test for typed function in decltype
--format=gnu-v3
_ZN1AIiE1jIiEEDTplfp_clL_Z1xvEEET_
-decltype ({parm#1}+((x())())) Aint::jint(int)
+decltype ({parm#1}+(x())) Aint::jint(int)
+# typed function in decltype with an argument list
+--format=gnu-v3
+_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv
+decltype (((long)(5))+(q(6))) tlong()
# test for expansion of function parameter pack
--format=gnu-v3
_Z1gIIidEEDTclL_Z1fEspplfp_Li1EEEDpT_
@@ -3990,6 +3994,18 @@ outer(short (*)(int), long)
_Z6outer2IsEPFilES1_
outer2short(int (*)(long))
#
+--format=gnu-v3 --no-params
+_ZN1KIXadL_ZN1S1mEiEEE1fEv
+KS::m::f()
+KS::m::f
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEiEEE1fEv
+K1, S::m::f()
+# Here the `(int)' argument list of `S::m' is already removed.
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1m1fEv
+K1, S::m::f()
+#
# Ada (GNAT) tests.
#
# Simple test.
Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)
On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
They should be supressed whenever the function appears in an
expression context, either as a pointer to member function (i.e. the
operand of '')
Done, therefore it is no longer restricted only to templates as before.
or as the function being called in a call expression.
I implemented it in the patch below but I do not agree + understand it.
The call expression is in libiberty/testsuite/demangle-expected modified by
this patch as:
# decltype/fn call test
--format=gnu-v3
_Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
-decltype (g({parm#1}, {parm#2})) add3int, double(int, double)
+decltype (g) add3int, double(int, double)
I agree it is sufficient to determine the return type just from the function
type as return type cannot be overloaded by the function parameters. But it
no longer matches a valid C++ source code now:
char g (int x, double y) { return 0; }
template typename T, typename U
decltype (g((T) 0, (U) 0)) add3 (T x, U y) { return 'z'; }
// error: ‘add3’ declared as function returning a function
// decltype (g) add3 (T x, U y) { return 'z'; }
int main () { add3int, double (1, 2.0); }
g++ -Wall -g -std=c++0x
g++ (GCC) 4.7.0 20110629 (experimental)
(Regression testing underway.)
Thanks,
Jan
libiberty/
2011-06-29 Jan Kratochvil jan.kratoch...@redhat.com
* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '' unary operator. Keep also already processed
variant without the argument list. Suppress argument list also for
function call used in an expression.
* testsuite/demangle-expected: Remove parameters from function call
expressions of 6 testcases. Create 3 new testcases for function
references by the '' unary operator..
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4139,7 +4169,46 @@ d_print_comp (struct d_print_info *dpi, int options,
return;
case DEMANGLE_COMPONENT_UNARY:
- if (d_left (dc)-type != DEMANGLE_COMPONENT_CAST)
+ if (d_left (dc)-type == DEMANGLE_COMPONENT_OPERATOR
+ d_left (dc)-u.s_operator.op-len == 1
+ d_left (dc)-u.s_operator.op-name[0] == ''
+ d_right (dc)-type == DEMANGLE_COMPONENT_TYPED_NAME
+ d_left (d_right (dc))-type == DEMANGLE_COMPONENT_QUAL_NAME
+ d_right (d_right (dc))-type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+ {
+ /* Address of a function (therefore in an expression context) must
+have its argument list suppressed.
+
+unary operator ... dc
+ operator ... d_left (dc)
+ typed name ... d_right (dc)
+qualified name ... d_left (d_right (dc))
+ names
+function type ... d_right (d_right (dc))
+ argument list
+arguments */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_left (d_right (dc)));
+ return;
+ }
+ else if (d_left (dc)-type == DEMANGLE_COMPONENT_OPERATOR
+ d_left (dc)-u.s_operator.op-len == 1
+ d_left (dc)-u.s_operator.op-name[0] == ''
+ d_right (dc)-type == DEMANGLE_COMPONENT_QUAL_NAME)
+ {
+ /* Keep also already processed variant without the argument list.
+
+unary operator ... dc
+ operator ... d_left (dc)
+ qualified name ... d_right (dc)
+names */
+
+ d_print_expr_op (dpi, options, d_left (dc));
+ d_print_comp (dpi, options, d_right (dc));
+ return;
+ }
+ else if (d_left (dc)-type != DEMANGLE_COMPONENT_CAST)
d_print_expr_op (dpi, options, d_left (dc));
else
{
@@ -4172,10 +4241,11 @@ d_print_comp (struct d_print_info *dpi, int options,
d_print_comp (dpi, options, d_right (d_right (dc)));
d_append_char (dpi, ']');
}
- else
+ /* Function call used in an expression should not have the argument list
+printed. */
+ else if (strcmp (d_left (dc)-u.s_operator.op-code, cl) != 0)
{
- if (strcmp (d_left (dc)-u.s_operator.op-code, cl) != 0)
- d_print_expr_op (dpi, options, d_left (dc));
+ d_print_expr_op (dpi, options, d_left (dc));
d_print_subexpr (dpi, options, d_right (d_right (dc)));
}
diff --git a/libiberty/testsuite/demangle-expected
b/libiberty/testsuite/demangle-expected
index bbd418c..da87282 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3904,7 +3904,7 @@ decltype ({parm#1}+{parm#2}) addint, double(int, double)
# decltype/fn call test
--format=gnu-v3
_Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
-decltype (g({parm#1}, {parm#2})) add3int, double(int, double)
+decltype (g) add3int, double(int, double)
# new (2008) built in types test
--format=gnu-v3
_Z1fDfDdDeDhDsDi
@@ -3916,15 +3916,15
[patch] libiberty/cp-demangle.c: Fix CP_DEMANGLE_DEBUG SIGSEGV
Hi, a mechanical patch which fixes during #define CP_DEMANGLE_DEBUG make check - /bin/sh: line 1: 9179 Segmentation fault ./test-demangle ./demangle-expected which also fixes confusing output for _Z1hI1AIiEdEDTcldtfp_1gIT0_EEET_S2_ binary operator arguments binary operator operator . binary operator arguments ???--- template name 'g' template argument list template parameter 1 argument list Thanks, Jan libiberty/ 2011-06-28 Jan Kratochvil jan.kratoch...@redhat.com * cp-demangle.c (d_dump): Add (zero-based) to DEMANGLE_COMPONENT_TEMPLATE_PARAM. Implement DEMANGLE_COMPONENT_FUNCTION_PARAM, DEMANGLE_COMPONENT_VECTOR_TYPE, DEMANGLE_COMPONENT_NUMBER, DEMANGLE_COMPONENT_GLOBAL_CONSTRUCTORS, DEMANGLE_COMPONENT_GLOBAL_DESTRUCTORS, DEMANGLE_COMPONENT_LAMBDA, DEMANGLE_COMPONENT_DEFAULT_ARG and DEMANGLE_COMPONENT_UNNAMED_TYPE. Print ??? %d on unknown dc-type. --- a/libiberty/cp-demangle.c +++ b/libiberty/cp-demangle.c @@ -506,7 +507,10 @@ d_dump (struct demangle_component *dc, int indent) printf (name '%.*s'\n, dc-u.s_name.len, dc-u.s_name.s); return; case DEMANGLE_COMPONENT_TEMPLATE_PARAM: - printf (template parameter %ld\n, dc-u.s_number.number); + printf (template parameter %ld (zero-based)\n, dc-u.s_number.number); + return; +case DEMANGLE_COMPONENT_FUNCTION_PARAM: + printf (function parameter %ld (zero-based)\n, dc-u.s_number.number); return; case DEMANGLE_COMPONENT_CTOR: printf (constructor %d\n, (int) dc-u.s_ctor.kind); @@ -633,6 +637,9 @@ d_dump (struct demangle_component *dc, int indent) case DEMANGLE_COMPONENT_FIXED_TYPE: printf (fixed-point type\n); break; +case DEMANGLE_COMPONENT_VECTOR_TYPE: + printf (vector type\n); + break; case DEMANGLE_COMPONENT_ARGLIST: printf (argument list\n); break; @@ -675,12 +682,35 @@ d_dump (struct demangle_component *dc, int indent) case DEMANGLE_COMPONENT_CHARACTER: printf (character '%c'\n, dc-u.s_character.character); return; +case DEMANGLE_COMPONENT_NUMBER: + printf (number %ld\n, dc-u.s_number.number); + return; case DEMANGLE_COMPONENT_DECLTYPE: printf (decltype\n); break; +case DEMANGLE_COMPONENT_GLOBAL_CONSTRUCTORS: + printf (global constructors keyed to name\n); + break; +case DEMANGLE_COMPONENT_GLOBAL_DESTRUCTORS: + printf (global destructors keyed to name\n); + break; +case DEMANGLE_COMPONENT_LAMBDA: + printf (lambda %d (zero-based)\n, dc-u.s_unary_num.num); + d_dump (dc-u.s_unary_num.sub, indent + 2); + return; +case DEMANGLE_COMPONENT_DEFAULT_ARG: + printf (default argument %d (zero-based)\n, dc-u.s_unary_num.num); + d_dump (dc-u.s_unary_num.sub, indent + 2); + return; +case DEMANGLE_COMPONENT_UNNAMED_TYPE: + printf (unnamed type %ld\n, dc-u.s_number.number); + return; case DEMANGLE_COMPONENT_PACK_EXPANSION: printf (pack expansion\n); break; +default: + printf (??? %d\n, dc-type); + break; } d_dump (d_left (dc), indent + 2);
[gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)
On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
Well, the basic issue is that the linkage name is produced by
libiberty/cp-demangle.c and the DW_AT_name is produced by
gcc/cp/error.c, and they don't always agree on the same
pretty-printed representation of a C++ expression.
Filed cross-check RFE GCC PR debug/49537 for it.
The function linkage name has prefix: K(S::m(int))
This isn't actually valid C++ syntax, so the demangler should be adjusted.
Attached. No regressions on gcc-4.6.0-10.fc15.x86_64. OK for check it in?
It fixes (and GDB commands start to work):
K(S::m(int))::f (this=0x7fffdcaf) at tmplmember.C:6
-
KS::m::f (this=0x7fffdcaf) at tmplmember.C:6
BTW the above change is when using DW_AT_linkage_name; FSF GDB HEAD still uses
physname computation but that is also not right:
K(S::m)::f (this=0x7fffdcaf) at tmplmember.C:6
--
struct S {
void m (int x) {}
};
templatevoid (S::*F) (int)
struct K {
void f () { S s; (s.*F) (5); }
};
int main () {
KS::m k;
k.f ();
}
--
Filed as GCC PR debug/49546 that GDB still does not work (*) for:
(*) without implementing - filed as GDB PR c++/12936:
On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
# Or maybe it is not a bug and one just has to accept the function prefix may
# not match its struct/class name?
# This would also be a good idea, for robustness when this kind of
# issue crops up.
--
struct S {
static void m (int x) {}
};
templatevoid (*T) (int)
// or: templatevoid (T) (int)
struct K {
void f () { T (0); }
};
int main () {
KS::m k;
// or: KS::m k;
k.f ();
}
--
DWARF is exactly the for all the four combination of alternative lines.
In the member function pointer above no alternative source form gets compiled.
As both KS::m::f() functions have exactly the same mangled name
_ZN1KIXadL_ZN1S1mEiEEE1fEv , the demangled names should match the source form
and in the first example it is the only allowed form of the source the
function should demangled to KS::m::f() - as it is by the patch below.
But in the second example the template instace `struct K' DW_AT_name is
KS::m so it cannot match the function KS::m::f() prefix.
But in the second case it also cannot always match the source form when
multiple source notations compile into exactly the same output.
FYI:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
qualified name
template
name 'K'
template argument list
unary operator
operator
typed name
qualified name
name 'S'
name 'm'
function type
argument list
builtin type int
name 'f'
function type
argument list
For GDB this patch resolves a regression of combination:
Re: [patch] Follow DW_AT_linkage_name for methods #2
http://sourceware.org/ml/gdb-patches/2011-06/msg00040.html
and
FYI: updates to temargs.exp
http://sourceware.org/ml/gdb-patches/2011-06/msg00138.html
On Wed, 22 Jun 2011 21:55:47 +0200, Gabriel Dos Reis wrote:
I agree this isn't valid C++ syntax. However, it is a syntax used in certain
popular frameworks, e.g. QT signal/slots, and it unambiguously tells in a
readable manner what function is intended from overload resolution
perspective.
There is now for some time for the template:
292: Abbrev Number: 11 (DW_TAG_template_value_param)
93 DW_AT_name: F
95 DW_AT_type: 0x16f
pointing (0x16f) to the member function so it is more up to the debugger (or
front-end) to show it. Had to file GDB PR c++/12933 for it, though.
Had to restrict the patch very much for the template function reference case as
otherwise the parameter types are required even in templates there.
Thanks,
Jan
libiberty/
2011-06-27 Jan Kratochvil jan.kratoch...@redhat.com
* cp-demangle.c (d_print_comp): Suppress argument list for function
references as template arguments.
* testsuite/demangle-expected: 3 new testcases for it.
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4095,7 +4095,56 @@ d_print_comp (struct d_print_info *dpi, int options,
case DEMANGLE_COMPONENT_ARGLIST:
case DEMANGLE_COMPONENT_TEMPLATE_ARGLIST:
if (d_left (dc) != NULL)
- d_print_comp (dpi, options, d_left (dc));
+ {
+ const struct demangle_component *left = d_left (dc);
+
+ if (dc-type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST
+ left-type == DEMANGLE_COMPONENT_UNARY
+ d_left (left)-type == DEMANGLE_COMPONENT_OPERATOR
+ d_left (left)-u.s_operator.op-len == 1
+ d_left (left)-u.s_operator.op-name[0
C++ member function template id not matching linkage name (PR debug/49408)
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49408
struct S {
void m (int x) {}
};
templatevoid (S::*F) (int)
struct K {
void f () { S s; (s.*F) (5); }
};
int main () {
KS::m k;
k.f ();
}
164: Abbrev Number: 8 (DW_TAG_structure_type)
65 DW_AT_name: KS::m
^
vs.
004004de W K(S::m(int))::f()
The function linkage name has prefix: K(S::m(int))
But DW_AT_name of that struct is: KS::m
They do not match.
But the struct DW_AT_name corresponds to the source literal 'KS::m'.
So maybe the function linkage name should be changed to: 'KS::m::f()'.
But changing the function linkage name would break ABI.
OTOH the function linkage name should probably refer to the fully qualified
'S::m' overload - to be able to look up 'S::m(int)' from the linkage name:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
qualified name
template
name 'K'
template argument list
unary operator
operator
typed name
qualified name
name 'S'
name 'm'
function type --- important to find 'S::m(int)'
argument list --- important to find 'S::m(int)'
builtin type int --- important to find 'S::m(int)'
name 'f'
function type
argument list
Or maybe it is not a bug and one just has to accept the function prefix may
not match its struct/class name?
Deciding how to deal with the GDB testcase:
gdb.cp/temargs.exp: test type of F in k2_m
Thanks for advice,
Jan
Re: [gcc patch 1/3] cp-demangle.c: Make `options' a parameter
On Mon, 13 Jun 2011 20:06:21 +0200, Ian Lance Taylor wrote:
The new options parameter should be the second parameter, not the last.
OK, I agree.
This is OK with those changes.
Checked in.
Thanks,
Jan
http://gcc.gnu.org/viewcvs?view=revisionrevision=174999
--- trunk/libiberty/ChangeLog 2011/06/13 19:05:04 174998
+++ trunk/libiberty/ChangeLog 2011/06/13 22:30:02 174999
@@ -1,3 +1,12 @@
+2011-06-13 Jan Kratochvil jan.kratoch...@redhat.com
+
+ * cp-demangle.c (struct d_print_info): Remove field options.
+ (d_print_init): Remove parameter options.
+ (cplus_demangle_print_callback): Update all the callers.
+ (d_print_comp, d_print_mod_list, d_print_mod, d_print_function_type)
+ (d_print_array_type, d_print_expr_op, d_print_cast, d_print_subexpr):
+ Add parameter options, update all the callers.
+
2011-04-20 Jim Meyering meyer...@redhat.com
* cp-demint.c (cplus_demangle_v3_components): Remove useless
--- trunk/libiberty/cp-demangle.c 2011/06/13 19:05:04 174998
+++ trunk/libiberty/cp-demangle.c 2011/06/13 22:30:02 174999
@@ -278,8 +278,6 @@
enum { D_PRINT_BUFFER_LENGTH = 256 };
struct d_print_info
{
- /* The options passed to the demangler. */
- int options;
/* Fixed-length allocated buffer for demangled data, flushed to the
callback with a NUL termination once full. */
char buf[D_PRINT_BUFFER_LENGTH];
@@ -436,7 +434,7 @@
d_growable_string_callback_adapter (const char *, size_t, void *);
static void
-d_print_init (struct d_print_info *, int, demangle_callbackref, void *);
+d_print_init (struct d_print_info *, demangle_callbackref, void *);
static inline void d_print_error (struct d_print_info *);
@@ -454,32 +452,32 @@
static inline char d_last_char (struct d_print_info *);
static void
-d_print_comp (struct d_print_info *, const struct demangle_component *);
+d_print_comp (struct d_print_info *, int, const struct demangle_component *);
static void
d_print_java_identifier (struct d_print_info *, const char *, int);
static void
-d_print_mod_list (struct d_print_info *, struct d_print_mod *, int);
+d_print_mod_list (struct d_print_info *, int, struct d_print_mod *, int);
static void
-d_print_mod (struct d_print_info *, const struct demangle_component *);
+d_print_mod (struct d_print_info *, int, const struct demangle_component *);
static void
-d_print_function_type (struct d_print_info *,
+d_print_function_type (struct d_print_info *, int,
const struct demangle_component *,
struct d_print_mod *);
static void
-d_print_array_type (struct d_print_info *,
+d_print_array_type (struct d_print_info *, int,
const struct demangle_component *,
struct d_print_mod *);
static void
-d_print_expr_op (struct d_print_info *, const struct demangle_component *);
+d_print_expr_op (struct d_print_info *, int, const struct demangle_component
*);
static void
-d_print_cast (struct d_print_info *, const struct demangle_component *);
+d_print_cast (struct d_print_info *, int, const struct demangle_component *);
static int d_demangle_callback (const char *, int,
demangle_callbackref, void *);
@@ -3293,10 +3291,9 @@
/* Initialize a print information structure. */
static void
-d_print_init (struct d_print_info *dpi, int options,
- demangle_callbackref callback, void *opaque)
+d_print_init (struct d_print_info *dpi, demangle_callbackref callback,
+ void *opaque)
{
- dpi-options = options;
dpi-len = 0;
dpi-last_char = '\0';
dpi-templates = NULL;
@@ -3392,9 +3389,9 @@
{
struct d_print_info dpi;
- d_print_init (dpi, options, callback, opaque);
+ d_print_init (dpi, callback, opaque);
- d_print_comp (dpi, dc);
+ d_print_comp (dpi, options, dc);
d_print_flush (dpi);
@@ -3537,7 +3534,7 @@
if needed. */
static void
-d_print_subexpr (struct d_print_info *dpi,
+d_print_subexpr (struct d_print_info *dpi, int options,
const struct demangle_component *dc)
{
int simple = 0;
@@ -3546,7 +3543,7 @@
simple = 1;
if (!simple)
d_append_char (dpi, '(');
- d_print_comp (dpi, dc);
+ d_print_comp (dpi, options, dc);
if (!simple)
d_append_char (dpi, ')');
}
@@ -3554,7 +3551,7 @@
/* Subroutine to handle components. */
static void
-d_print_comp (struct d_print_info *dpi,
+d_print_comp (struct d_print_info *dpi, int options,
const struct demangle_component *dc)
{
if (dc == NULL)
@@ -3568,7 +3565,7 @@
switch (dc-type)
{
case DEMANGLE_COMPONENT_NAME:
- if ((dpi-options DMGL_JAVA) == 0)
+ if ((options DMGL_JAVA) == 0)
d_append_buffer (dpi, dc-u.s_name.s, dc-u.s_name.len);
else
d_print_java_identifier (dpi, dc-u.s_name.s, dc-u.s_name.len);
@@ -3576,12 +3573,12 @@
case DEMANGLE_COMPONENT_QUAL_NAME:
case
Re: [gcc patch 2/3] cp-demangle.c: New DMGL_RET_DROP
On Mon, 13 Jun 2011 20:08:40 +0200, Ian Lance Taylor wrote: On Thu, Jun 2, 2011 at 7:16 AM, Jan Kratochvil jan.kratoch...@redhat.com wrote: include/ 2011-05-24 Jan Kratochvil jan.kratoch...@redhat.com * demangle.h (DMGL_RET_POSTFIX): Extend the comment. (DMGL_RET_DROP): New. libiberty/ 2011-05-24 Jan Kratochvil jan.kratoch...@redhat.com * cp-demangle.c (d_print_comp) DEMANGLE_COMPONENT_FUNCTION_TYPE: Do not pass DMGL_RET_POSTFIX or DMGL_RET_DROP. Support DMGL_RET_DROP. * testsuite/demangle-expected: New testcases for --ret-drop. * testsuite/test-demangle.c: Document --ret-drop in a comment. (main): New variable ret_drop, fill it, call cplus_demangle with it. This is OK. Checked in: http://gcc.gnu.org/viewcvs?view=revisionrevision=175000 Thanks, Jan
Re: [gcc patch 3/3] cp-demangle.c: Fix DMGL_RET_POSTFIX for inner func types
On Mon, 13 Jun 2011 20:09:57 +0200, Ian Lance Taylor wrote: On Thu, Jun 2, 2011 at 7:17 AM, Jan Kratochvil jan.kratoch...@redhat.com wrote: libiberty/ 2011-05-24 Jan Kratochvil jan.kratoch...@redhat.com * cp-demangle.c (d_print_comp) DEMANGLE_COMPONENT_FUNCTION_TYPE: Suppress d_print_mod for DMGL_RET_POSTFIX. * testsuite/demangle-expected: New testcases for --ret-postfix. This is OK. Checked in: http://gcc.gnu.org/viewcvs?view=revisionrevision=175001 Thanks, Jan
[gcc patch 0/3] libiberty: New DMGL_RET_DROP
Hi,
introducing DMGL_RET_DROP which suppresses return type demangled from linkage
name for the toplevel function type.
DMGL_RET_POSTFIX is now in use only for DMGL_JAVA. Besides Java return types
in linkage name are in C++ present for function templates.
GDB since 7.2 provides convenience alias for the function template symbols
without the return type so that for
00400523 T _Z4funcIdET_i
00400523 T double funcdouble(int)
one can since GDB 7.2 easily find the template functions by name using:
(gdb) break funtab-completion
instead of having to guess the return type first as in GDB 7.1:
(gdb) break 'double funtab-completion
As the demangler usage has been reintroduced for GDB 7.3 (to fix GDB PR 12506
and similar cases by using DW_AT_linkage_name again) it now needs to drop the
return type by the demangler (instead of a GDB 7.2 custom physname code).
The function templates return types linkage name are a similar case like
DMGL_JAVA which uses DMGL_RET_POSTFIX:
jmain.main(java.lang.String[])void
I believe both cases should either use DMGL_RET_POSTFIX or the new
DMGL_RET_DROP, therefore to use just:
jmain.main(java.lang.String[])
For C++ I (and also Tom Tromey) prefer DMGL_RET_DROP:
funcdouble(int)
over DMGL_RET_POSTFIX:
funcdouble(int)double
as in practice there are no two template function instances with the same name
+ parameters signature but different return type - one cannot overload
function by return type in either C++ or Java. G++ rejects compilation of
a CU containing such two instances, one can only link two different CUs
together to get the return type linkage name difference in a single file.
After all one also still can reference the function by its original ELF symbol
'double funcdouble(int)'. Proposing in a different GDB patch to use
DMGL_RET_DROP even for Java symbols but I do not have any real need for it.
This patchset had no GCC regressions for Fedora gcc-4.6.0-8.fc15 (not tested
for GCC HEAD, hopefully OK).
The new testcases are based on a C++ source:
template typename T
char outer (int (*inner) (long)) { return 0; }
int outer2_ret (long) { return 0; }
template typename T
int (*outer2 (int (*inner) (long))) (long) { return outer2_ret; }
char outer (short (*inner) (int), long) { outer2short (0); return
outershort (0); }
Thanks,
Jan
[gcc patch 3/3] cp-demangle.c: Fix DMGL_RET_POSTFIX for inner func types
Hi,
I do not need this patch in any way but I believe it should go in for the case
anyone would want to use DMGL_RET_POSTFIX with C/C++.
Without this fix the new testcase would:
FAIL at line 3979, options --format=gnu-v3 --ret-postfix:
in: _Z6outer2IsEPFilES1_
out: outer2short(int (*)(long))int (*(int (*)(long)))(long)
exp: outer2short(int (*)(long))int (*)(long)
Thanks,
Jan
libiberty/
2011-05-24 Jan Kratochvil jan.kratoch...@redhat.com
* cp-demangle.c (d_print_comp) DEMANGLE_COMPONENT_FUNCTION_TYPE:
Suppress d_print_mod for DMGL_RET_POSTFIX.
* testsuite/demangle-expected: New testcases for --ret-postfix.
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3921,7 +3921,10 @@ d_print_comp (struct d_print_info *dpi, const struct
demangle_component *dc,
options ~(DMGL_RET_POSTFIX | DMGL_RET_DROP));
/* Print return type if present */
- if (d_left (dc) != NULL (options DMGL_RET_DROP) == 0)
+ if (d_left (dc) != NULL (options DMGL_RET_POSTFIX) != 0)
+ d_print_comp (dpi, d_left (dc),
+ options ~(DMGL_RET_POSTFIX | DMGL_RET_DROP));
+ else if (d_left (dc) != NULL (options DMGL_RET_DROP) == 0)
{
struct d_print_mod dpm;
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3968,6 +3968,15 @@ outer(short (*)(int), long)
--format=gnu-v3
_Z6outer2IsEPFilES1_
int (*outer2short(int (*)(long)))(long)
+--format=gnu-v3 --ret-postfix
+_Z5outerIsEcPFilE
+outershort(int (*)(long))char
+--format=gnu-v3 --ret-postfix
+_Z5outerPFsiEl
+outer(short (*)(int), long)
+--format=gnu-v3 --ret-postfix
+_Z6outer2IsEPFilES1_
+outer2short(int (*)(long))int (*)(long)
--format=gnu-v3 --ret-drop
_Z5outerIsEcPFilE
outershort(int (*)(long))
Re: [PATCH] PR debug/47471 (set prologue_end in .debug_line)
On Thu, 31 Mar 2011 04:59:18 +0200, Richard Henderson wrote: On 03/30/2011 11:19 AM, Dodji Seketeli wrote: First, it avoids emitting two consecutive .loc that are identical. Strictly speaking that should fix this issue in this particular case. What's the compatibility strategy? I.e. how does gdb tell that we're not using the double-loc mechanism? Does it scan the line ops and if you see any prologue_end marks assume that double-loc is not in effect? Currently GDB ignores / has no support for DW_LNS_set_prologue_end. Are you actually going to be able to delete any code within gdb, due to the need to interpret older debug info? No code is going to be deleted from GDB. For -O2 -g code the prologue does not (will not) need to be known to GDB: [patch] Do not skip prologue for -O2 -g with GCC VTA Re: [patch] Fix for PR gdb/12573 http://sourceware.org/ml/gdb-patches/2011-03/msg01129.html For -O0 -g code the line number information may be good enough. For compatibility with older GDBs the line number tricks should remain in place and in such case DW_LNS_set_prologue_end is redundant for -O0 -g. I thought DW_LNS_set_prologue_end would be cleaner for -O0 -g but that may not be required. Thanks, Jan
Re: debugging
On Wed, 23 Mar 2011 08:51:25 +0100, Jakub Jelinek wrote: http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval is the git branch with gdb support for this, though as I was told it is a GDB 7.4 material rather than 7.3 (the msg00268.html commit is hopefully GDB 7.3 material). Yes it is on HEAD, 7.3 is not yet branched, gdb-7.3 will consider 0xf3 as standard optimized out (like before the gcc patch). Discussed at: [patch] [entryval] fixup: Unhandled dwarf expression opcode 0xf3 http://sourceware.org/ml/gdb-patches/2011-03/msg00965.html GDB is now in something like stage 3 for gdb-7.3. The full support from archer-jankratochvil-entryval will go in GDB HEAD after 7.3 gets branched/released. Thanks, Jan
Build regression [Re: [patch libiberty include]: Add additional helper functions for directory-separator searching]
On Wed, 09 Mar 2011 13:58:38 +0100, Pedro Alves wrote: Thanks. I've applied it. nto-tdep.c:130:8: error: assignment discards ‘const’ qualifier from pointer target type [-Werror] gcc-4.6.0-0.12.fc15.x86_64 --with-system-zlib --enable-64-bit-bfd --enable-targets=all --enable-static --disable-shared --enable-debug --disable-sim --enable-gold --with-separate-debug-dir=/usr/lib/debug CC=gcc CFLAGS=-m64 -ggdb2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 LDFLAGS= -lmcheck commit 7403e6b3f0f7d4c4f80703486f602ee5e2c9a3dd Author: Pedro Alves pe...@codesourcery.com Date: Wed Mar 9 12:48:53 2011 + * cli/cli-cmds.c (shell_escape): Use lbasename. * coffread.c (coff_start_symtab): Constify parameter. (complete_symtab): Constify `name' parameter. (coff_symtab_read): Constify `filestring' local. (coff_getfilename): Constify return and `result' local. Use lbasename. * fbsd-nat.c (fbsd_make_corefile_notes): Use lbasename. * linux-fork.c (info_checkpoints_command): Use lbasename. * linux-nat.c (linux_nat_make_corefile_notes): Use lbasename. * minsyms.c (lookup_minimal_symbol): Use lbasename. * nto-tdep.c (nto_find_and_open_solib): Use lbasename. * procfs.c (procfs_make_note_section): Use lbasename. * tui/tui-io.c (printable_part): Constity return and parameter. Use lbasename. (print_filename): Constify parameters, and local `s'. (tui_rl_display_match_list): Constify local `temp'. Thanks, Jan
Re: Build regression [Re: [patch libiberty include]: Add additional helper functions for directory-separator searching]
On Wed, 09 Mar 2011 16:02:36 +0100, Pedro Alves wrote: Thanks, had forgotten --enable-targets=all. Sorry about that. It builds now OK. Thanks, Jan
Re: dwarf2 - multiple DW_TAG_variable for global variable
On Sun, 10 Jan 2010 00:31:56 +0100, Nenad Vukicevic wrote: ... 154: Abbrev Number: 4 (DW_TAG_variable) 55 DW_AT_name: (indirect string, offset: 0x38): x 59 DW_AT_decl_file : 1 5a DW_AT_decl_line : 1 5b DW_AT_type: 0x4d 5f DW_AT_external: 1 60 DW_AT_declaration : 1 161: Abbrev Number: 5 (DW_TAG_variable) 62 DW_AT_name: (indirect string, offset: 0x38): x 66 DW_AT_decl_file : 1 67 DW_AT_decl_line : 1 68 DW_AT_type: 0x4d 6c DW_AT_external: 1 6d DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) in 4.4.1 and 4.5 releases. Any idea if this is a correct dwarf? Or must be treated as a duplicate somehow? It does not hurt much GDB - if the debugger ignores the second definition it looks as a declaration of external symbol and it gets correctly looked up through the ELF (not DWARF) .symtab symbol without using DW_AT_location. PR 39524 mentions a special scope case which gets broken by it but in common cases it works fine. Regards, Jan
