extract_includes.bat file path with spaces does not copy header files #1264
Comments
ejsd1989
changed the title
|
This is a known issue. The current setup of extract_includes.bat doesn't allow spaces in file paths. |
|
@xfxyjwf i see. Given that it's a known issue, should my issue post remain? Also, is anyone currently assigned/attempting to solve the issue? |
copybara-service bot
pushed a commit
that referenced
this issue
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this issue
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this issue
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this issue
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684620833
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I wanted to post to the group page prior to posting anything on here, just in case my issue is created by my own setup. But i'm not sure if it posted there. So here we go posting it directly to the github.
This was during an attempt to just get the tutorial working.
I'm running on a Windows 10 system, and using VS 2013.
I was attempting to run the extract_includes.bat in my release directory that was compiled using nmake, and nothing was copying over. Running tests.exe worked fine though.
In either case, I needed to modify the .bat file to include quotes ("") around the file paths that had spaces.
Edit Is this something related to the install.cmake file? Is there a need to parse the PROTOBUF_SOURCE_WIN32_PATH to check and adjust for spaces? Or am i just making things up?
I'm not sure if this is necessarily an issue or just due to my setup. I'd be interested in perhaps tracking down how the .bat is being created and see if it's related to the actual creation. But, i don't want to go searching down a rabbit hole if it's just a problem that i created myself.
Any tips or suggestions?
Thanks.
The text was updated successfully, but these errors were encountered: