Support maximum of 64kB page on aarch64 #3146

yuyichao · 2022-04-11T22:20:52Z

Build the preload library to be aligned to 64kB following the default of binutils.

I've never used capnp before and I'm not sure yet how to add and use a new header field.....

If I'm doing things correctly, this should not affect x86...

Fix #3143

yuyichao · 2022-04-14T00:42:19Z

I've cleaned up the commit a bit, now there are a few relatively standalone commits here that should hopefully help with reviewing. Most of the commits are refactoring that doesn't make a difference on x86.
Some of the commits can be its own PR, one of which is Consistently use 4k as the size unit for mmap2-like internal functions #3154. Since I think this is fully ready now I'm not going to split any out ATM into their own PR.
No separate linker script anymore. Use configure file instead.
It should be relatively easy to change the build time page size in the future, as shown in the last commit.
I've added two fields in the header for the runtime page size and the build time page size as suggested by @rocallahan

rocallahan · 2022-04-15T10:00:51Z

src/preload/syscall_hook.S

        .set preload_thread_locals,0x70001000
+#endif


Why doesn't this use 0x70000000 + RR_PAGE_SIZE?

This one was actually just because I was too lazy to check if the macro was defined by this point ;-p...

rocallahan · 2022-04-15T10:01:18Z

src/test/mmap_replace_most_mappings.c

 #define RR_THREAD_LOCALS_PAGE_ADDR 0x70001000
+#endif


Likewise this could be RR_PAGE_ADDR + page_size()?

This is in the test so it's somewhat different. It would have to be rr_page_size() as well.

rocallahan

I think you mean librrpreload.so, not librrpage.so?

I think we should move rr_page_size() to to util.h/util.cc as a global function that's a peer of page_size(). I think we should also change its name ... how about rr_max_supported_page_size() since it's the the maximum page size supported by this build of rr (which is baked into librrpreload.so layout)?

yuyichao · 2022-04-15T15:40:58Z

I'm fine with renaming. I pick the current name mainly to emphasize that it's the size of the block in the preload library, since that's actually what most of the code uses it for (they use that size with a multiplication factor to compute an offset/address). It's somewhat less obvious what address + n * maximum_support_page_size means but as I said, I don't feel too strong about it either...

yuyichao · 2022-04-15T15:50:26Z

I also realized that I left one instance of RR_PAGE_SIZE unchanged so I'll need to fix that...

I also did only minimum amount of refactoring but I could refactor it more to make most things that need a page size to get them from fewer places. I wasn't sure how much to abstract out/assume but I guess I'll just assume that we'll have an architecture dependent maximum page size to support and refactor everything around that. If there's an architecture that doesn't have a upper limit for page size it might be a problem but I think the system linker would also have to make such a decision anyway.....

rocallahan · 2022-04-15T21:19:03Z

OK how about calling it preload_library_page_size() and document that it's the maximum supported page size for this architecture/rr build?

yuyichao · 2022-04-16T17:43:51Z

Is there any specific reason to have both a function version rr_page_size() and a macro/constant version RR_PAGE_SIZE of seemingly the same thing? Should they be merged/both renamed?

rocallahan · 2022-04-16T22:06:02Z

You're right. We should just have a PRELOAD_LIBRARY_PAGE_SIZE constant and use that everywhere.

yuyichao · 2022-04-16T22:09:07Z

OK, so there's no need to make it arch dependent at runtime? I guess we can worry about that if/when there's support for cross architecture record/replay?...

rocallahan · 2022-04-16T22:10:19Z

This has to be a build-time property because it determines the layout of the preload library.

yuyichao · 2022-04-16T22:11:41Z

But in principle it only need to be a build time property librrpage.so (pretty sure this is the one I'm talking about, not librrpreload.so), the rr binary could accept multiple sizes and pick them at runtime.....

Anyway, constant it is for now...

rocallahan · 2022-04-16T22:14:25Z

Right. I want it in the trace header so that later we can change the value for a given architecture and extend rr to support replaying "old" traces with a different value, so it would have to be a function outside the preload library. But we don't need to do that now.

Just to be consistent on what we use

To better reflect what we use this for. This is the size of the blocks (pages) within librrpage.so and we use this size mostly for computing addresses within/around that file.

PRELOAD_LIBRARY_PAGE_SIZE is the size/alignment of librrpage.so which is determined at compile time. It should not depend on the runtime system page size.

Use a cmake variable to control the page size/alignment used by the linker script and the tweak script.

…ZE in the trace In case we need to retrieve this information in a future version.

Build the preload library to be aligned to 64kB following the default of binutils. Fix rr-debugger#3143

yuyichao · 2022-04-16T22:43:08Z

I updated with the new name and replaced all use of rr_page_size with the constant. As shown in the last commit, there are still a few (5) places where this value is defined. This is because, AFAICT, these do not include a shared header.

The simplest method to avoid this is to just add a add_definitions(-DPRELOAD_LIBRARY_PAGE_SIZE=${PRELOAD_LIBRARY_PAGE_SIZE}). Maybe even an PRELOAD_LIBRARY_PAGE_SHIFT so that rr_page.S doesn't have to hard code another value that may get out of sync. However, this would mean that the header would be less standalone which is a minor concern since preload_interface.h is installed. If someone is relying on preload_interface.h being usable (granted the renaming would have broke the API) an alternative is to use configure_file to create a header with this value. If that's not a concern I can just go with add_definitions.

yuyichao · 2022-04-16T22:45:32Z

(The new field in the trace file header is also updated)

rocallahan · 2022-04-18T11:51:12Z

I think this is good enough for now.

rocallahan · 2022-04-18T12:12:27Z

Actually I added a followup patch 9d623e8 to set the default page size to its correct value, and made the page sizes UInt32.

yuyichao force-pushed the aarch64-64kpage branch from c433c07 to 26e5e06 Compare April 11, 2022 22:21

yuyichao mentioned this pull request Apr 11, 2022

Support apple M1 #3144

Merged

5 tasks

yuyichao force-pushed the aarch64-64kpage branch 3 times, most recently from 38934bb to 1b8a024 Compare April 12, 2022 12:06

yuyichao mentioned this pull request Apr 13, 2022

Consistently use 4k as the size unit for mmap2-like internal functions #3154

Merged

yuyichao force-pushed the aarch64-64kpage branch 4 times, most recently from 5958ebd to e54fe7d Compare April 14, 2022 00:33

yuyichao force-pushed the aarch64-64kpage branch 2 times, most recently from 4f47bcd to d48aa8e Compare April 15, 2022 00:55

rocallahan requested changes Apr 15, 2022

View reviewed changes

yuyichao force-pushed the aarch64-64kpage branch from d48aa8e to 472e9c7 Compare April 15, 2022 14:00

yuyichao force-pushed the aarch64-64kpage branch from 472e9c7 to 5806c1e Compare April 16, 2022 17:33

yuyichao added 4 commits April 16, 2022 18:16

Replace rr_page_size() with RR_PAGE_SIZE constant

c11e542

Just to be consistent on what we use

Rename RR_PAGE_SIZE to PRELOAD_LIBRARY_PAGE_SIZE

fbb3b93

To better reflect what we use this for. This is the size of the blocks (pages) within librrpage.so and we use this size mostly for computing addresses within/around that file.

Use the correct version of page sizes

8af31b9

PRELOAD_LIBRARY_PAGE_SIZE is the size/alignment of librrpage.so which is determined at compile time. It should not depend on the runtime system page size.

Prepare the build system for supporting larger page size

1321f98

Use a cmake variable to control the page size/alignment used by the linker script and the tweak script.

yuyichao added 2 commits April 16, 2022 18:34

Save the runtime page size and the build time PRELOAD_LIBRARY_PAGE_SI…

d1fd6fb

…ZE in the trace In case we need to retrieve this information in a future version.

Support maximum of 64kB page on aarch64

088a501

Build the preload library to be aligned to 64kB following the default of binutils. Fix rr-debugger#3143

yuyichao force-pushed the aarch64-64kpage branch from 5806c1e to 088a501 Compare April 16, 2022 22:36

rocallahan merged commit 9300470 into rr-debugger:master Apr 18, 2022

yuyichao deleted the aarch64-64kpage branch April 18, 2022 11:52

yuyichao mentioned this pull request May 19, 2022

Implement syscallbuf on aarch64 #3235

Merged

Techcable mentioned this pull request Aug 15, 2022

Binary releases of fd crash on Asahi Linux because of jemalloc using 8kb page sizes sharkdp/fd#1085

Closed

theofficialgman mentioned this pull request Nov 22, 2022

Jemalloc needs support for 16KB pages on Apple Silicon Linux LWJGL/lwjgl3#828

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support maximum of 64kB page on aarch64 #3146

Support maximum of 64kB page on aarch64 #3146

yuyichao commented Apr 11, 2022 •

edited

yuyichao commented Apr 14, 2022

rocallahan Apr 15, 2022

yuyichao Apr 15, 2022

rocallahan Apr 15, 2022

yuyichao Apr 15, 2022

rocallahan left a comment •

edited

yuyichao commented Apr 15, 2022

yuyichao commented Apr 15, 2022

rocallahan commented Apr 15, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 18, 2022

rocallahan commented Apr 18, 2022

Support maximum of 64kB page on aarch64 #3146

Support maximum of 64kB page on aarch64 #3146

Conversation

yuyichao commented Apr 11, 2022 • edited

yuyichao commented Apr 14, 2022

rocallahan Apr 15, 2022

Choose a reason for hiding this comment

yuyichao Apr 15, 2022

Choose a reason for hiding this comment

rocallahan Apr 15, 2022

Choose a reason for hiding this comment

yuyichao Apr 15, 2022

Choose a reason for hiding this comment

rocallahan left a comment • edited

Choose a reason for hiding this comment

yuyichao commented Apr 15, 2022

yuyichao commented Apr 15, 2022

rocallahan commented Apr 15, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 16, 2022

yuyichao commented Apr 16, 2022

yuyichao commented Apr 16, 2022

rocallahan commented Apr 18, 2022

rocallahan commented Apr 18, 2022

yuyichao commented Apr 11, 2022 •

edited

rocallahan left a comment •

edited