From: "H. J. Lu" <hjl@lucon.org>
To: gcc@gcc.gnu.org, GDB <gdb@sources.redhat.com>
Subject: Gdb generates DW_OP_fbreg in location list without DW_AT_frame_base
Date: Thu, 30 Dec 2004 20:52:00 -0000 [thread overview]
Message-ID: <20041230205202.GA17785@lucon.org> (raw)
In-Reply-To: <20041230202828.GA11668@nevyn.them.org>
On Thu, Dec 30, 2004 at 03:28:28PM -0500, Daniel Jacobowitz wrote:
> On Thu, Dec 30, 2004 at 12:23:46PM -0800, H. J. Lu wrote:
> > On Thu, Dec 30, 2004 at 03:07:20PM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote:
> > > > DW_AT_frame_base may be needed for location lists of local variables.
> > > > But in case of tls_symbolic_operand, there is no local variable.
> > > > Location lists are used for function parameters.
> > >
> > > Then why is GDB calling get_frame_base? It is only called for
> > > DW_OP_fbreg. If we don't have a frame base, we don't know what
> > > DW_OP_fbreg refers to.
> >
> > Gcc generates:
> >
> > <1><28c955>: Abbrev Number: 47 (DW_TAG_subprogram)
> > DW_AT_sibling : <28c98f>
> > DW_AT_external : 1
> > DW_AT_name : (indirect string, offset: 0x3875d):
> > tls_symbolic_operand
> > DW_AT_decl_file : 1
> > DW_AT_decl_line : 471
> > DW_AT_prototyped : 1
> > DW_AT_type : <2887cb>
> > DW_AT_low_pc : 0x826c1d0
> > DW_AT_high_pc : 0x826c1fc
> > <2><28c96f>: Abbrev Number: 48 (DW_TAG_formal_parameter)
> > DW_AT_name : op
> > DW_AT_decl_file : 1
> > DW_AT_decl_line : 470
> > DW_AT_type : <288a7b>
> > DW_AT_location : 120fbf (location list)
> > <2><28c97e>: Abbrev Number: 49 (DW_TAG_formal_parameter)
> > DW_AT_name : (indirect string, offset: 0x3db66): mode
> > DW_AT_decl_file : 1
> > DW_AT_decl_line : 470
> > DW_AT_type : <288e5d>
> > DW_AT_location : 121018 (location list)
> >
> > for
> >
> > int
> > tls_symbolic_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
> > {
> > return ((GET_CODE (op) == SYMBOL_REF) && (SYMBOL_REF_TLS_MODEL (op)
> > != 0)) && (mode == VOIDmode || GET_MODE (op) == mode);
> > }
> >
> > It may be a gcc bug after all.
>
> And what's in the location lists? If it's DW_OP_fbreg, then I presume
> it's a GCC bug. According to my reading of the DWARF spec, anyway.
>
<1><418c>: Abbrev Number: 47 (DW_TAG_subprogram)
DW_AT_sibling : <41c6>
DW_AT_external : 1
DW_AT_name : (indirect string, offset: 0x3133): tls_symbolic_operand
DW_AT_decl_file : 1
DW_AT_decl_line : 471
DW_AT_prototyped : 1
DW_AT_type : <2c>
DW_AT_low_pc : 0x2f0
DW_AT_high_pc : 0x31c
<2><41a6>: Abbrev Number: 48 (DW_TAG_formal_parameter)
DW_AT_name : op
DW_AT_decl_file : 1
DW_AT_decl_line : 470
DW_AT_type : <2dc>
DW_AT_location : 549 (location list)
<2><41b5>: Abbrev Number: 49 (DW_TAG_formal_parameter)
DW_AT_name : (indirect string, offset: 0x44e5): mode
DW_AT_decl_file : 1
DW_AT_decl_line : 470
DW_AT_type : <6be>
DW_AT_location : 5a2 (location list)
00000549 000002f0 000002fe (DW_OP_fbreg: 4)
00000549 000002fe 00000300 (DW_OP_reg0)
00000549 00000300 00000301 (DW_OP_fbreg: 4)
00000549 00000301 0000030b (DW_OP_reg0)
00000549 0000030b 00000311 (DW_OP_fbreg: 4)
00000549 00000311 00000315 (DW_OP_reg0)
00000549 00000315 0000031c (DW_OP_fbreg: 4)
000005a2 000002f0 000002fe (DW_OP_fbreg: 8)
000005a2 000002fe 0000031c (DW_OP_reg2)
next prev parent reply other threads:[~2004-12-30 20:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-22 1:16 Is this a gcc, gdb or readelf bug? H. J. Lu
2004-12-22 11:09 ` Nick Clifton
2004-12-22 18:25 ` H. J. Lu
2004-12-23 3:43 ` Daniel Jacobowitz
2004-12-30 19:24 ` GDB 6.3 assumes that DW_AT_frame_base exists H. J. Lu
2004-12-30 19:36 ` H. J. Lu
2004-12-30 19:56 ` H. J. Lu
2004-12-30 20:07 ` Daniel Jacobowitz
2004-12-30 20:23 ` Gdb generates location list without DW_AT_frame_base H. J. Lu
2004-12-30 20:28 ` Daniel Jacobowitz
2004-12-30 20:52 ` H. J. Lu [this message]
2004-12-30 20:56 ` Daniel Berlin
2004-12-30 21:05 ` H. J. Lu
2004-12-31 0:35 ` Daniel Berlin
2004-12-31 19:57 ` H. J. Lu
2004-12-31 20:09 ` Daniel Berlin
2004-12-31 20:11 ` H. J. Lu
2004-12-31 20:16 ` Daniel Berlin
[not found] ` <20041231163806.GA1335@lucon.org>
[not found] ` <Pine.LNX.4.60.0412311158280.27590@dberlin.org>
[not found] ` <20041231184405.GA2182@lucon.org>
[not found] ` <Pine.LNX.4.60.0412311451060.6844@dberlin.org>
[not found] ` <Pine.LNX.4.60.0412311509360.6844@dberlin.org>
[not found] ` <20041231215010.GA5722@lucon.org>
[not found] ` <20041231215443.GA5853@lucon.org>
[not found] ` <Pine.LNX.4.60.0412311656360.6844@dberlin.org>
[not found] ` <20041231220324.GA5987@lucon.org>
2005-01-01 19:15 ` gcc 4.0 " H. J. Lu
2005-01-01 20:09 ` Daniel Jacobowitz
2005-01-01 20:50 ` Daniel Berlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041230205202.GA17785@lucon.org \
--to=hjl@lucon.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox