This is an archive of the discontinued LLVM Phabricator instance.

[Sanitizer] Update GetMaxVirtualAddress for PowerPC64 Linux
AbandonedPublic

Authored by foad on Nov 3 2014, 5:29 AM.

Details

Summary

On PowerPC64 the sanitizers currently have no reliable way of detecting whether we're using 44- or 46-bit virtual addressing.

Linux switched from 44- to 46-bit in release 3.7, so this patch calls uname(2) and checks the Linux release string to decide what to return. This gets some basic sanitizer functionality working for me on big-endian Fedora 19 (Linux 3.14).

I've left the non-Linux defaults alone, even though they seem pretty arbitrary: 44-bit for big-endian and 46-bit for little-endian.

See also the discussion here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

Diff Detail

Event Timeline

foad updated this revision to Diff 15690.Nov 3 2014, 5:29 AM
foad retitled this revision from to [Sanitizer] Update GetMaxVirtualAddress for PowerPC64 Linux.
foad updated this object.
foad edited the test plan for this revision. (Show Details)
foad added reviewers: kcc, samsonov, willschm.
foad added a subscriber: Unknown Object (MLST).
kcc edited edge metadata.Nov 3 2014, 10:42 AM

Do we need to support 44-bit AS at all?
Why not just support the new ans shiny 46 bit?

If we absolutely need this, maybe try mapping something in a few different places and see if 46 bits work?

willschm edited edge metadata.Nov 3 2014, 2:12 PM

Hi Jay,

Can you see if the updated patch from ( http://reviews.llvm.org/D6044 ) works for you.   It should work for both old and new kernels, etc.
foad added a comment.Nov 3 2014, 2:12 PM
In D6082#4, @kcc wrote:

Do we need to support 44-bit AS at all?
Why not just support the new ans shiny 46 bit?

I can't answer that. It's a question for the sanitizer maintainers. Do you want to support PowerPC64 on Linux older than 3.7 (released about two years ago)? Do you support PowerPC64 on any other OSes?

Personally, I'd be very happy with only supporting 46-bit. But I was trying to be conservative, by fixing the modern Linux case but not breaking any other setups that might already have been working.

If we absolutely need this, maybe try mapping something in a few different places and see if 46 bits work?

Sure, if you'd prefer that approach, I'll try to come up with a patch.

kcc added a comment.Nov 3 2014, 2:31 PM

I am always reluctant to support any old OS (and > 2+ years is old) unless there is a specific request and someone is willing to do the support work.
My team currently does't test on PowerPC at all. So, the simplest solution (i.e. only support 46-bit and assert at run-time if the OS is old) seems best for me.

foad added a comment.Nov 3 2014, 2:46 PM

OK, so we could go with Will's patch from D6044, or simplify even further to just:

return (1ULL << 46) - 1;

What do you think, Will?

In D6082#7, @kcc wrote:

I am always reluctant to support any old OS (and > 2+ years is old) unless there is a specific request and someone is willing to do the support work.
My team currently does't test on PowerPC at all. So, the simplest solution (i.e. only support 46-bit and assert at run-time if the OS is old) seems best for me.

In D6082#8, @foad wrote:

OK, so we could go with Will's patch from D6044, or simplify even further to just:

return (1ULL << 46) - 1;

What do you think, Will?

Roughly half of the systems I'm running on are old enough that they use the 44-bit address space, so I would prefer to allow those to continue working. :-) At least until they fail for some other difficult reason, at least.
When the address space is wrongly calculated, the tests tend to hang or spin rather than crash and terminate,.. so if we decide that 44-bit address space will not be supported, we'll want to have an explicit abort of some sort.

foad abandoned this revision.Nov 4 2014, 2:31 AM
In D6082#9, @willschm wrote:

Roughly half of the systems I'm running on are old enough that they use the 44-bit address space, so I would prefer to allow those to continue working. :-) At least until they fail for some other difficult reason, at least.

Fair enough. In that case I humbly withdraw this patch; let's go with D6044 instead. It sounds like you're best placed to test this stuff anyway, Will.