public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Bill Seurer <seurer@linux.vnet.ibm.com>
Cc: marxin <mliska@suse.cz>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 0/7] libsanitizer: merge from trunk
Date: Fri, 26 Oct 2018 15:32:00 -0000	[thread overview]
Message-ID: <20181026145247.GV11625@tucnak> (raw)
In-Reply-To: <2b41845a-6680-9635-a6fb-046ed5e38332@linux.vnet.ibm.com>

On Fri, Oct 26, 2018 at 09:48:54AM -0500, Bill Seurer wrote:
> On 10/26/18 03:57, Jakub Jelinek wrote:
> > On Thu, Oct 25, 2018 at 12:49:42PM +0200, Jakub Jelinek wrote:
> > > On Thu, Oct 25, 2018 at 12:15:46PM +0200, marxin wrote:
> > > > I've just finished my first merge from libsanitizer mainline. Overall it
> > > > looks fine, apparently ABI hasn't changed and so that SONAME bump is not
> > > > needed.
> > > 
> > > Given the 6/7 patch, I think you need to bump libasan soname (it would be
> > > weird to bump it on powerpc64* only).
> > 
> > BTW, how can shadow offset be 1UL<<44 on powerpc64?  That seems like they
> > don't want to support anything but very recent kernels.
> > E.g. looking at Linux 3.4 arch/powerpc/include/asm/processor.h
> > I see
> > /* 64-bit user address space is 44-bits (16TB user VM) */
> > #define TASK_SIZE_USER64 (0x0000100000000000UL)
> > so, the new choice must be incompatible with lots of kernels out there.
> > Move recent kernels have:
> > #define TASK_SIZE_64TB  (0x0000400000000000UL)
> > #define TASK_SIZE_128TB (0x0000800000000000UL)
> > #define TASK_SIZE_512TB (0x0002000000000000UL)
> > #define TASK_SIZE_1PB   (0x0004000000000000UL)
> > #define TASK_SIZE_2PB   (0x0008000000000000UL)
> > #define TASK_SIZE_4PB   (0x0010000000000000UL)
> > but 4.15 still tops at 512TB, 4.10 has just 64TB as the only choice, 3.8 as
> > well.
> > 
> > CCing Bill as he made this change.
> > 
> > 	Jakub
> > 
> 
> At the time for llvm the concern was to get it to work on newer kernels and
> not worry (much) about the older ones.  I did spend some time trying to get
> it to work for both.

Which exact task size doesn't work if shadow offset is 2TB and why?

	Jakub

  reply	other threads:[~2018-10-26 14:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25 11:06 marxin
2018-10-25 10:41 ` [PATCH 7/7] Update test-suite expected output after rewording in libsanitizer marxin
2018-10-25 10:41 ` [PATCH 4/7] Apply LOCAL_PATCHES and remove not used ones marxin
2018-10-25 10:46 ` [PATCH 5/7] New local GCC patch for CAN_SANITIZE_UB ifdef marxin
2018-10-25 10:52 ` [PATCH 3/7] Update build system: include new files and run autoheader, autoconf, automake marxin
2018-10-31 11:31   ` Rainer Orth
2018-10-31 11:31     ` Martin Liška
2018-10-25 10:53 ` [PATCH 6/7] Adjust asan_shadow_offset for powerpc64 targets marxin
2018-10-25 11:16 ` [PATCH 1/7] Update merge script and HOWTO_MERGE documentation marxin
2018-10-25 12:00 ` [PATCH 2/7] Merge from upstream 345033 Martin Liška
2018-10-25 12:31 ` [PATCH 0/7] libsanitizer: merge from trunk Jakub Jelinek
2018-10-25 12:33   ` Martin Liška
2018-10-26  9:57   ` Jakub Jelinek
2018-10-26 15:25     ` Bill Seurer
2018-10-26 15:32       ` Jakub Jelinek [this message]
2018-10-29 13:31         ` Martin Liška
2018-10-29 13:32           ` Jakub Jelinek
2018-10-29 14:29             ` Bill Seurer
2018-10-29 16:34               ` Michael Matz
2018-10-29 17:43                 ` Bill Seurer
2018-10-29 17:47                   ` Jakub Jelinek
2018-10-31  9:40                     ` Jakub Jelinek
2018-10-25 12:55 ` [PATCH 8/N] Bump libasan version due to adjustement in shadow memory offset for ppc64 target Martin Liška
2018-10-31 11:35 ` [PATCH 0/7] libsanitizer: merge from trunk Martin Liška
2018-10-31 11:55   ` Jakub Jelinek

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=20181026145247.GV11625@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=seurer@linux.vnet.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).