public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Timo Kreuzer <timo.kreuzer@web.de>
To: gcc-help@gcc.gnu.org
Subject: Problem
Date: Wed, 19 Nov 2008 17:22:00 -0000	[thread overview]
Message-ID: <49244161.3010706@web.de> (raw)

Hi,

I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
codes to mark the code positions where the try block starts / ends and
of the except landing pad. The emitted .eh_frame section is parsed after
linking and converted into Windows compatible unwind info / scope tables.
This works quite well so far.

Now the problem: The exception filter and the finally clause are being
created as nested functions. Now I need to know (in the parsing step
after linking) the addresses of these functions and that they belong to
the corresponding try / except statement. Best would be emitting the
address of the nested function as .cfi_escape, but that doesn't really
work. 1) .cfi_escape only takes bytes, not rvas and 2) the C compiler
doesn't want to give me the address of the nested function at compile time.

I ended up with a dirty hack, referencing the "parent code" from the
inline function with a lea opcode:

{
    __label__ label1;
label1:
    asm volatile (".cfi_escape 0x50, 0x01\n");
    int nested_function()
    {
        asm volatile ("lea %0, %%eax" : : "m"(*(volatile
int*)(&&label1)) : "eax" )
        asm volatile (".cfi_escape 0x50, 0x02\n");
    }
}

From the escape code I know that there must be a lea instruction, that I
can read the rva from. Together with the position of the start of the
nested function and the position of the label (that would correspond to
the end of the try block for example), I have all the information.
But it's dirty.

Does anyone know a better solution for that?

Thanks in advance,
Timo



             reply	other threads:[~2008-11-19 16:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 17:22 Timo Kreuzer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-09-29  9:55 Problem sl529
2004-07-08 15:30 Problem m waqar
2004-07-08 15:26 Problem m waqar
2004-07-08 15:32 ` Problem Eljay Love-Jensen
1999-12-10 17:02 Problem Alexander Pochaevets
1999-12-31 22:24 ` Problem Alexander Pochaevets

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=49244161.3010706@web.de \
    --to=timo.kreuzer@web.de \
    --cc=gcc-help@gcc.gnu.org \
    /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).