How to run SuperSize on Android binary?

[Cherie Cheung]

Hi,

I read about android-binary-size trybot to monitor size regression in Android and it is based on SuperSize. 

We, ARCVM team, would like to perform a similar analysis on our ARCVM Android binary (an Android branch from R currently). Can you give us some pointers on how to run SuperSize on an Android binary? We do not need to set up continuous monitoring at the moment and simply want to do a one-off measurement for analysis. Our goal is to find ways to shrink the ARCVM Android binary.

Thank you.

Cherie

[Andrew Grieve]

SuperSize has some pretty chromium-specific logic in it, but it's likely that you'll be able to use it somewhat at least.

Specifically, it parses build.ninja to find the list of input object files for the link step, and to map object file paths to source paths. 

We try to keep it usable for non-chromium binaries, but that flow does tend to break from time to time. Happy to try and help fix things up if it doesn't work, but just warning that it may require some code tweaks.

So... that size, you should be able to get it to produce a minimal .size file given just a linker map file and an unstripped binary. 

To get a linker map file, link with "-Wl,-Map=mylinker.map" 

Then run the tool like:

tools/binary_size/supersize archive myfile.size --elf-file unstripped_binary --map-file mylinker.map --no-source-paths --tool-prefix=$CHROMIUM_SRC/third_party/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-

(you probably want to point the --tool-prefix to your copy of the ndk & for the correct architecture.

Final note - while the python code is mostly self-contained within //tools, there are dependencies outside of //tools. It will be easiest to just do a full chromium checkout (run "fetch android", where "fetch" is in depot_tools)

--
You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/c0bacc9d-c492-4472-9535-a3f71d87d158n%40chromium.org.

[Andrew Grieve]

If you do manage to create a .size file, you can view it here.

[Cherie Cheung]

Thanks, I'll try to see if I can get a linker map file and an unstripped binary first.

Given that android-binary-size trybot is already set up and running, is there anything I can borrow from that setup? (e.g. How did they get a linker map file and an unstripped binary?)

Our ARCVM binary is very similar to a normal Android binary, with some customization logic for Chrome OS integration.

Cherie

[Andrew Grieve]

We have our build system configured to produce linker map files for all binaries compiled with is_official_build GN arg. The recipe doesn't do anything there other than set the GN arg.

Unstripped binaries are always available as the output of builds (likely true for Android as well, as you can't symbolize stack traces without them).

So yeah, I don't think the recipe buys you anything. It's job is basically:

1 build with patch

2. run supersize

3. build without patch

4. run supersize

5. upload results

[Cherie Cheung]

Hi Andrew,

I think I might have misunderstood the use of android-binary-size trybot earlier.

It's called "Android" binary size trybot, but it's actually measuring the size of Chrome libraries (e.g. libmonochrome) used in Android platforms.

Looking at the LUCI runs here, they are all Chrome builds as well.

It does not support binary size analysis on Android yet, but it's something that I can try. Is that right?

Thank you.

Cherie

[Andrew Grieve]

Ah, yes, that's right. It's entirely a chrome bot.

[Cherie Cheung]

Thanks for clarifying. I'll see if there is anything we can borrow from this for Android analysis.

Cherie