From: Florian Weimer <fweimer@redhat.com>
To: Josef Wolf <jw@raven.inka.de>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Propagating addresses from linker to the runtie
Date: Fri, 18 Oct 2019 09:15:00 -0000 [thread overview]
Message-ID: <87d0euv2hh.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20191018090705.GF11171@raven.inka.de> (Josef Wolf's message of "Fri, 18 Oct 2019 11:07:05 +0200")
* Josef Wolf:
> Strictly speaking, the symbols defined by the linker (_sidata, _sdata, _edata,
> _sbss and _ebss) are unrelated when seen from the perspective of the
> compiler. Therefore, it is not allowed by the standard to use their addresses
> for comparison.
>
> So what would be the proper way to pass this information from the linker to the
> compiler?
In glibc, we use this:
/* Perform vtable pointer validation. If validation fails, terminate
the process. */
static inline const struct _IO_jump_t *
IO_validate_vtable (const struct _IO_jump_t *vtable)
{
/* Fast path: The vtable pointer is within the __libc_IO_vtables
section. */
uintptr_t section_length = __stop___libc_IO_vtables - __start___libc_IO_vtables;
uintptr_t ptr = (uintptr_t) vtable;
uintptr_t offset = ptr - (uintptr_t) __start___libc_IO_vtables;
if (__glibc_unlikely (offset >= section_length))
/* The vtable pointer is not in the expected section. Use the
slow path, which will terminate the process if necessary. */
_IO_vtable_check ();
return vtable;
}
I do not know how effective this is.
In C++, you can use std::less, which was enhanced to cover your use
case.
Thanks,
Florian
next prev parent reply other threads:[~2019-10-18 9:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 13:19 Crash when cross compiling for ARM with GCC-8-2-0 and -ftree-loop-distribute-patterns Josef Wolf
2019-10-16 13:30 ` Matthias Pfaller
2019-10-17 8:10 ` Josef Wolf
2019-10-16 18:18 ` Martin Sebor
2019-10-17 11:40 ` Josef Wolf
2019-10-17 12:37 ` Matthias Pfaller
2019-10-17 14:10 ` Josef Wolf
2019-10-17 14:55 ` Richard Earnshaw (lists)
2019-10-18 9:00 ` Josef Wolf
2019-10-18 10:26 ` Richard Earnshaw (lists)
2019-10-18 12:10 ` Josef Wolf
2019-10-18 13:07 ` Segher Boessenkool
2019-10-18 13:40 ` Josef Wolf
2019-10-18 12:50 ` Josef Wolf
2019-10-18 14:04 ` Richard Earnshaw (lists)
2019-10-18 9:10 ` Propagating addresses from linker to the runtie (was: Re: Crash when cross compiling for ARM with GCC-8-2-0 and) -ftree-loop-distribute-patterns Josef Wolf
2019-10-18 9:15 ` Florian Weimer [this message]
2019-10-18 9:50 ` Propagating addresses from linker to the runtie Josef Wolf
2019-10-18 10:47 ` Florian Weimer
2019-10-18 12:51 ` Segher Boessenkool
2019-10-18 12:56 ` Florian Weimer
2019-10-18 14:14 ` Segher Boessenkool
2019-10-18 14:34 ` Florian Weimer
2019-10-18 13:30 ` Josef Wolf
2019-10-18 14:20 ` Segher Boessenkool
2019-10-18 13:10 ` Crash when cross compiling for ARM with GCC-8-2-0 and -ftree-loop-distribute-patterns Josef Wolf
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=87d0euv2hh.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=gcc-help@gcc.gnu.org \
--cc=jw@raven.inka.de \
/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).