public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matthew Plant <rookie.mp@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Question regarding the values of labels
Date: Tue, 01 Nov 2011 23:52:00 -0000	[thread overview]
Message-ID: <CAOyYdLcnsSCqGznXuoMNZuPwy-U0WXdQ=y8iTnJShQG4Ma_6ag@mail.gmail.com> (raw)

Hello there people who are much smarter than me,

A little background on my problem:
I'm trying to implement a simple JIT compiler, and to do this I
decided the best way would be by using the GNU GCC unary && operator.
Instead of having to write target assembly for each platform my
program is going to be on (along with writing a runtime assembler,
which I do not want to do), I figured I'd take sections of C code
wrapped in labels like so:

block_begin:
 {
   <instruction code>
 }
block_end:;

Then I can simply copy the bytes between block_begin and block_end
into an allocated char array, repeat as necessary for as many blocks
as I am wont, finally cast to a function pointer and voilà, I have a
JIT compiler. Of course control flow is incredibly messy (or an offset
has to be added to all the jump addresses), but it's still decently
simple.

Unfortunately, as I expected it would be, it wasn't actually that
simple. Perhaps there is some inherent flaw in my thinking, but for
now, on to the problem that occurs:

For some reason, the location of labels in memory changes depending on
the control flow of the program. I have this test program which just
prints the addresses of the labels in the program:

#include <stdio.h>
#include <stdlib.h>
int main ()
{
  int i;
 lbl1:
  i = 32;
 lbl2:
  i += 4;
 lbl3:
  i += 5;
  printf ("%lu, %lu, %lu, %lu\n", main, &&lbl1, &&lbl2, &&lbl3);
  return 0;
}

A sample run prints out something like 4195524, 4195532, 4195539,
4195543. That's all good and dandy. The labels are all a reasonable
distance from each other and there are no repeat values.
But say we decide to alter the control flow a bit:

#include <stdio.h>
#include <stdlib.h>
int main ()
{
  int i;
  goto lbl3;
 lbl1:
  i = 32;
  goto done;
 lbl2:
  i += 4;
 lbl3:
  i += 5;
  printf ("%lu, %lu, %lu, %lu\n", main, &&lbl1, &&lbl2, &&lbl3);
 done:;
  return 0;
}

A resulting sample output is 4195524, 4195533, 4195532, 4195533. What
the heck?! Two of the labels have the same address, and the second
label comes before the third and first! This was compiled without any
optimizations and the values did not differ upon adding
__attribute__((__noinline__,__noclone__)) or setting the addresses to
static variables.

So my final question is this: what determines the addresses of labels?
Can this problem be fixed with at least semi-readable code?

Any help would be greatly appreciated.

Sincerely,
Matt

             reply	other threads:[~2011-11-01 23:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 23:52 Matthew Plant [this message]
2011-11-02  0:56 ` Ian Lance Taylor
2011-11-02  0:56 ` Ian Lance Taylor
2011-11-02 10:04 ` Andrew Haley

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='CAOyYdLcnsSCqGznXuoMNZuPwy-U0WXdQ=y8iTnJShQG4Ma_6ag@mail.gmail.com' \
    --to=rookie.mp@gmail.com \
    --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).