public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Henderson <rth@twiddle.net>
Cc: Kai Tietz <ktietz70@googlemail.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: 64-bit pei vs dwarf2
Date: Tue, 28 Sep 2010 16:41:00 -0000	[thread overview]
Message-ID: <20100928082343.GS1269@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <4CA136DF.7000406@twiddle.net>

On Mon, Sep 27, 2010 at 05:29:19PM -0700, Richard Henderson wrote:
> The 64-bit PEI format has a SECREL32 relocation type.  It
> does not, however, have a SECREL64 relocation type.  Which
> means that for
> 
> > #define DWARF_REF_SIZE  \
> >   (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
> 
> we don't really have something to use for for dwarf2.
> 
> I could fake it with
> 
> 	.secrel32	ref
> 	.long		0

This is something we already use for TLS on x86_64:
        .byte   0xa     # DW_AT_location
        .byte   0xe     # DW_OP_const8u
        .long   i@dtpoff, 0
At least for relocations that are always resolved to locations
within the same .debug_info section they will be always unsigned
and thus using .secrel 32 ref; .long 0 is IMHO just fine, and
implicit pointer currently will never reference anything outside of the
current executable's or shared library's CU.

Other alternative would be e.g. to have some macro to protect uses of
DW_FORM_ref_addr/DW_OP_GNU_implicit_pointer/DW_OP_call_ref,
which by default would be to enable them e.g. for
(dwarf_version >= 3 || !dwarf_strict) and targets
like this could restrict them to (dwarf_version >= 3).

	Jakub

  parent reply	other threads:[~2010-09-28  8:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28 10:44 Richard Henderson
2010-09-28 12:28 ` Dave Korn
2010-09-28 15:21 ` Kai Tietz
2010-09-28 16:29   ` Kai Tietz
2010-09-28 16:41 ` Jakub Jelinek [this message]
2010-09-28 17:07   ` Kai Tietz
2010-09-28 17:22     ` Andrew Haley
2010-09-28 19:21     ` Richard Henderson
2010-09-28 21:24       ` Kai Tietz
2010-09-28 22:51         ` Richard Henderson

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=20100928082343.GS1269@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=ktietz70@googlemail.com \
    --cc=rth@twiddle.net \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).