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: [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
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_cast (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
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 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
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 t
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
--- a
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 > wrote: > > gdb/testsuite/ > > 2013-02-02 Jan Kratochvil > > > > 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
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
-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 [10
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
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) {}
};
template
struct K {
void f () { S s; (s.*F) (5); }
};
int main () {
K<&S::m> k;
k.f ();
}
<1><64>: Abbrev Number: 8 (DW_TAG_structure_type)
<65> DW_AT_name: K<&S::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: K<&S::m>
They do not match.
But the struct DW_AT_name corresponds to the source literal 'K<&S::m>'.
So maybe the function linkage name should be changed to: 'K<&S::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: 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 (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
Re: dwarf2 - multiple DW_TAG_variable for global variable
On Sun, 10 Jan 2010 00:31:56 +0100, Nenad Vukicevic wrote: ... > <1><54>: 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 > <1><61>: 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
Re: dwarf2 - multiple DW_TAG_variable for global variable
On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote: > On 01/09/10 12:39:55, Nenad Vukicevic wrote: > > This dwarf code started appearing since this patch: > > Here's the GCC bug report that led to this patch: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563 Such DIEs duplicities are being tracked at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524 (Unaware how/if any were caused by the PR 39563.) Regards, Jan
Re: Strange error message from gdb
On Thu, 20 Dec 2007 15:33:14 +0100, Andrew Haley wrote: > Alexandre Oliva writes: > > > > How about this patch, instead? It will restore debuggability to Java > > while at the same time maintaining the progress of using the > > long-supported-by-GDB DW_TAG_class_type in both C++ and Java. > > > > for gcc/java/ChangeLog > > from Alexandre Oliva <[EMAIL PROTECTED]> > > > > * lang.c (java_classify_record): Don't return > > RECORD_IS_INTERFACE for now. > > > > OK, thanks. FYI GDB HEAD supports it now (just the backward compatible way, no new info extracted from it so far). http://sourceware.org/ml/gdb-cvs/2007-12/msg00123.html Regards, Jan
[PATCH] Re: Unwinding CFI gcc practice of assumed `same value' regs
Hi, On Tue, 12 Dec 2006 16:52:33 +0100, Jakub Jelinek wrote: ... > Here is something that would handle by default same_value retaddr_column: [ http://sources.redhat.com/ml/gdb/2006-12/msg00100.html ] Thanks for this backward compatible glibc unwinder patch. I wish to have it accepted as a step in preparing the environment to use `.cfi_undefined PC' sometimes in the future. Attaching patch for current glibc CVS which removes the `.cfi_undefined PC' unwinder handling requirement but which provides explicit return address 0 from the `__clone' function. Currently the 0 is already present there but it is uninitialized value out of some TLS or 'struct pthread' area (did not check). Attaching patch for current gdb CVS to properly terminate on return address 0. The check was already present there but it got applied one backward step later. I hope these three patches are be 100% reliable and also backward compatible. Regards, Jan 2006-12-13 Jan Kratochvil <[EMAIL PROTECTED]> * sysdeps/unix/sysv/linux/i386/clone.S: CFI `clone' unwinding outermost frame indicator replaced by more unwinders compatible termination indication of `PC == 0'. * sysdeps/unix/sysv/linux/x86_64/clone.S: Likewise. --- libc/sysdeps/unix/sysv/linux/i386/clone.S 3 Dec 2006 23:12:36 - 1.27 +++ libc/sysdeps/unix/sysv/linux/i386/clone.S 13 Dec 2006 11:20:55 - @@ -68,6 +68,8 @@ ENTRY (BP_SYM (__clone)) thread is started with an alignment of (mod 16). */ andl$0xfff0, %ecx subl$28,%ecx + /* Terminate the stack frame by pretended return address 0. */ + movl$0,16(%ecx) movlARG(%esp),%eax /* no negative argument counts */ movl%eax,12(%ecx) @@ -121,10 +123,15 @@ L(pseudo_end): L(thread_start): cfi_startproc; - /* Clearing frame pointer is insufficient, use CFI. */ - cfi_undefined (eip); - /* Note: %esi is zero. */ - movl%esi,%ebp /* terminate the stack frame */ + /* This CFI recommended way of unwindable function is incompatible + across unwinders incl. the libgcc_s one. + cfi_undefined (eip); + */ + /* Frame pointer 0 was considered as the stack frame termination + before but it is no longer valid for -fomit-frame-pointer code. + Still keep the backward compatibility and clear the register. + Note: %esi is zero. */ + movl%esi,%ebp #ifdef RESET_PID testl $CLONE_THREAD, %edi je L(newpid) --- libc/sysdeps/unix/sysv/linux/x86_64/clone.S 3 Dec 2006 23:12:36 - 1.7 +++ libc/sysdeps/unix/sysv/linux/x86_64/clone.S 13 Dec 2006 11:20:55 - @@ -61,8 +61,12 @@ ENTRY (BP_SYM (__clone)) testq %rsi,%rsi /* no NULL stack pointers */ jz SYSCALL_ERROR_LABEL + /* Prepare the data located at %rsp after `syscall' below. + Used only 3*8 bytes but the stack is 16 bytes aligned. */ + subq$32,%rsi + /* Terminate the stack frame by pretended return address 0. */ + movq$0,16(%rsi) /* Insert the argument onto the new stack. */ - subq$16,%rsi movq%rcx,8(%rsi) /* Save the function pointer. It will be popped off in the @@ -90,10 +94,15 @@ L(pseudo_end): L(thread_start): cfi_startproc; - /* Clearing frame pointer is insufficient, use CFI. */ - cfi_undefined (rip); - /* Clear the frame pointer. The ABI suggests this be done, to mark - the outermost frame obviously. */ + /* This CFI recommended way of unwindable function is incompatible + across unwinders incl. the libgcc_s one. + cfi_undefined (rip); + */ + /* Frame pointer 0 was considered as the stack frame termination + before but it is no longer valid for -fomit-frame-pointer code. + Still keep the backward compatibility and clear the register, + the ABI suggests this be done, to mark the outermost frame + obviously. */ xorl %ebp, %ebp #ifdef RESET_PID 2006-12-13 Jan Kratochvil <[EMAIL PROTECTED]> * gdb/frame.c (get_prev_frame): Already the first `PC == 0' stack frame is declared invalid, not the second one as before. 2006-12-13 Jan Kratochvil <[EMAIL PROTECTED]> * gdb.threads/bt-clone-stop.exp, gdb.threads/bt-clone-stop.c: Backtraced `clone' must not have `PC == 0' as its previous frame. --- ./gdb/frame.c 10 Nov 2006 20:11:35 - 1.215 +++ ./gdb/frame.c 13 Dec 2006 19:06:19 - @@ -1390,19 +1390,28 @@ get_prev_frame (struct frame_info *this_ return NULL; } + prev_frame = get_prev_frame_1 (this_frame); + if (!prev_frame) +return NULL; + /* Assume that the only way to get a zero PC is through something li
Re: Unwinding CFI gcc practice of assumed `same value' regs
On Tue, 12 Dec 2006 16:26:34 +0100, Andrew Haley wrote:
...
> It's certainly an inconsistency in the specification, which says that
> null-termination is supported, and this implies that you can't put a zero in
> there.
I tested now that you can put the zero there for both the libgcc unwinder and
for gdb(1) [tested only Fedora Core gdb-6.5-13.fc6],
attached, on x86_64 compile [gcc-4.1.1-30] and run by:
gcc -o fp0-x86_64 -O9 -fomit-frame-pointer -Wall fp0-x86_64.c -ggdb3;
./fp0-x86_64
The output provided at the end of this mail.
Therefore I believe this sentence is wrong and it should be removed:
http://www.x86-64.org/documentation/abi.pdf (draft 0.98) Page 28
(29/124)
%rbp ... but the user code should mark the deepest stack frame by
%setting the frame pointer to zero.
On the other hand the right stack terminator for libgcc unwinder is `PC == 0':
unwind-dw2.c:uw_frame_state_for ():
if (context->ra == 0)
return _URC_END_OF_STACK;
And gdb should just get updated to behave the same way.
libunwind already assumed end of stack on `PC == 0' before and I do not expect
any platform would consider `PC == 0' as a valid _return_address_ (which is
usually several bytes after any starting function address due to the call
instruction).
...
> "All of these" might be the right way to go. That is, keep
> null-terminating the stack, strengthen the rules about what you might
> do with %ebp, and extend debuginfo.
For best compatibility null terminate the stack but by CFI and its indicated
return address. Do not use %rbp (frame pointer register) in any way (regarding
the stack termination condition).
Believe only CFI-specified CFA address, unrelated to %rbp content.
Regards,
Jan
--
GNU gdb Red Hat Linux (6.5-13.fc6rh)
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".
(gdb) b 12
Breakpoint 1 at 0x40060b: file fp0-x86_64.c, line 12.
(gdb) r
Starting program: /root/jkratoch/redhat/unwind/fp0-x86_64
Breakpoint 1, backtracer () at fp0-x86_64.c:12
12 int i = backtrace (buf, 512);
(gdb) bt
#0 backtracer () at fp0-x86_64.c:12
#1 0x00400739 in badone () at fp0-x86_64.c:31
#2 0x0040074e in main () at fp0-x86_64.c:47
(gdb) p/x $rbp
$1 = 0x7fff6ed61ca0
(gdb) up
#1 0x00400739 in badone () at fp0-x86_64.c:31
31 backtracer ();
(gdb) p/x $rbp
$2 = 0x0
(gdb) c
Continuing.
dummy
5
/root/jkratoch/redhat/unwind/fp0-x86_64[0x40062c]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x400739]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x40074e]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x301e81da44]
/root/jkratoch/redhat/unwind/fp0-x86_64[0x400559]
Program received signal SIGSEGV, Segmentation fault.
0x00400684 in backtracer () at fp0-x86_64.c:21
21 RAFA(1);
(gdb) q
#include
#include
#include
#include
static void backtracer (void) __attribute__((__noinline__));
static void backtracer (void)
{
void *buf[512];
puts("dummy");
int i = backtrace (buf, 512);
printf ("%d\n", i);
fflush (stdout);
backtrace_symbols_fd (buf, i, STDOUT_FILENO);
#define RAFA(level) \
printf("RA (%d) = %p, FA (%d) = %p\n", \
level, __builtin_return_address (level), \
level, __builtin_frame_address (level))
RAFA(0);
RAFA(1);
RAFA(2);
RAFA(3);
RAFA(4);
RAFA(5);
}
static int badone (void) __attribute__((__noinline__));
static int badone (void)
{
backtracer ();
return 0;
}
asm(
" .text \n"
"clearstack:\n"
" pushq $0 \n"
" popq%rax\n"
" ret \n"
);
extern void clearstack(void);
int main (void)
{
clearstack ();
badone ();
return 0;
}
Unwinding CFI gcc practice of assumed `same value' regs
Hello, currently (on x86_64) the gdb backtrace does not properly stop at the outermost frame: #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 #5 0x in ?? () Currently it relies only on clearing %rbp (0x above is unrelated to it, it got read from uninitialized memory). http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame pointer 0x0 should be enough for a debugger not finding CFI to stop unwinding, still it is a heuristic. In the -fno-frame-pointer compiled code there is no indication the frame pointer register became a regular one and 0x0 is its valid value. The right unwinding stop indication should be CFI-undefined PC: http://dwarf.freestandards.org/Dwarf3.pdf - page 118 (130/267) - If a Return Address register is defined in the virtual unwind table, and its rule is undefined (for example, by DW_CFA_undefined), then there is no return address and no call address, and the virtual unwind of stack activations is complete. It has been recently patched for glibc clone() (as the outermost frame) http://sourceware.org/ml/libc-alpha/2006-11/msg00082.html but it had to be reverted as the current libgcc_s unwinder is incompatible: http://sourceware.org/ml/libc-alpha/2006-12/msg00078.html Current libgcc_s unwinder does not differentiate between `DW_CFA_undefined' and `DW_CFA_same_value' as both set a register state to its `REG_UNSAVED'. Updating its behavior unfortunately relies on another current ABI incoherency as DWARF specifies all the registers should be `undefined' by default http://dwarf.freestandards.org/Dwarf3.pdf - page 111 (123/267) - The default rule for all columns before interpretation of the initial instructions is the undefined rule. However, an ABI authoring body or a compilation system authoring body may specify an alternate default value for any or all columns. but current gcc produces CFI code assuming the default state of all the registers is `same value'. The strictly DWARF compliant gcc behavior would be to initialize all the callee saved registers to `DW_CFA_same_value' in all the CIE initial instructions blocks. This is currently not done and it would introduce a large increase of `.eh_frame' size, despite the merging of common CIEs. Therefore (Jakub is) proposing for gcc `compilation system authoring' to define the default callee saved registers as `same value' and callee unsaved registers as `undefined'. It would make the current gcc CFI practice stanards compliant and the unwinding stop CFI would became clear and -fomit-frame-pointer reliable. GCC: `unwind-dw2' needs update to differentiate `undefined' and `same value'. AFAIK its code (CFI) generator may remain the same. GLIBC: Reintroduce the patch above utilizing `.cfi_undefined rip'. GDB: The currently disabled (default `set complaints 0') warnings made obsolete: During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0xfc1400. Other unwinders: May need fix to support `DW_CFA_undefined', done for libunwind. Most of the problem analysis by the courtesy of Jakub Jelinek. Not providing any patches so far until the final solution decision is made. Regards, Jan
[32bit] `main' missing argc/argv DW_AT_location
Hi, is it a known bug that `main' function (and so even specially compiled with the specific prologue/epilogue) missing DWARF `DW_AT_location' for its `argc' and `argv' on 32-bit targets? I did not find a Bugzilla entry for it. affected: x86_64-redhat-linux with -m32, i386-redhat-linux not affected: x86_64-redhat-linux (-m64) 32-bit broken for: gcc-4.1.1, snapshot 4.2.0 always works: gcc-3.4.6 It causes gdb(1) to hide the arguments during backtrace: #0 main () at test.c:3 Thanks, Jan correct (gcc-3.4.6): <1>: Abbrev Number: 33 (DW_TAG_subprogram) DW_AT_sibling : DW_AT_external: 1 DW_AT_name: main DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_prototyped : 1 DW_AT_type: DW_AT_low_pc : 0x8048c0f DW_AT_high_pc : 0x8048e26 DW_AT_frame_base : 616(location list) <2>: Abbrev Number: 34 (DW_TAG_formal_parameter) DW_AT_name: argc DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_type: DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0) <2>: Abbrev Number: 34 (DW_TAG_formal_parameter) DW_AT_name: argv DW_AT_decl_file : 46 DW_AT_decl_line : 267 DW_AT_type: DW_AT_location: 2 byte block: 91 4 (DW_OP_fbreg: 4) incorrect (gcc-4.1.1): <1><64>: Abbrev Number: 2 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: main DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_prototyped : 1 DW_AT_type: <9b> DW_AT_low_pc : 0x8048324 DW_AT_high_pc : 0x804833d DW_AT_frame_base : 0 (location list) DW_AT_sibling : <9b> <2><82>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_name: argc DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_type: <9b> <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_name: argv DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_type:
