fix: ignore the 'B' augmentation character when reading CIE info.

[jianliang00]

Some compilers emit a B augmentation character that Bloaty does not currently handle. This patch ignores it because it is not useful for binary size analysis and should not break the process.

ref: llvm-mirror/libunwind@0930d6c

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[EricRahm]

Overall lgtm, thanks for the contribution! One small request, one bigger request:

1. Can you include a more detailed commit message and reference issue #450?
2. We'd like to start including lit tests for things like this. There are examples under tests/. Is that something you'd be interested in taking care of?

[EricRahm]

Makes sense to me, we might also consider handling G while we're at it. I think similarly that's a flag and we can just ignore it. What do you think?

[jianliang00]

I haven’t come across this tag before, but after looking into it, it does seem like it can be safely ignored. I'll add it in this patch.

[jianliang00]

Overall lgtm, thanks for the contribution! One small request, one bigger request:

1. Can you include a more detailed commit message and reference issue Unexpected augmentation character: B #450?
2. We'd like to start including lit tests for things like this. There are examples under tests/. Is that something you'd be interested in taking care of?

Thank you for your reply. I checked the tests directory and tried adding a case to verify this patch, but I found it difficult to reproduce a minimal binary that includes a G/B augmentation. I may need a bit more time to figure out how to produce it. Do you have any suggestions? @EricRahm

[EricRahm]

Thank you for your reply. I checked the tests directory and tried adding a case to verify this patch, but I found it difficult to reproduce a minimal binary that includes a G/B augmentation. I may need a bit more time to figure out how to produce it. Do you have any suggestions? @EricRahm

There's a couple approaches we could take:

1. Copy / trim down something like our existing normal-obj.test, we'd modify the Contents of the .eh_frame section:
   

   bloaty/tests/elf/sections/normal-obj.test

   Lines 40 to 44 in c3e1ba1

   	- Name: .eh_frame
   	Type: SHT_X86_64_UNWIND
   	Flags: [ SHF_ALLOC ]
   	AddressAlign: 0x0000000000000008
   	Content: 1400000000000000017A5200017810011B0C0708900100001C0000001C000000000000000B00000000410E108602430D06460C0708000000

2. If you have an existing binary with these attributes you can use obj2yaml, musl-static-bin.test took this approach:
   

   bloaty/tests/elf/sections/musl-static-bin.test

   Lines 1 to 19 in c3e1ba1

   	# A fully statically-linked binary linked with musl.
   	# Program text was:
   	#
   	# char x[123] = {0};
   	# char y[456] = {1, 2, 3};
   	# const char z[789] = {1, 2, 3};
   	#
   	# int main() {
   	# volatile long addr = (long)&x;
   	# addr = (long)&y;
   	# addr = (long)&z;
   	# return 5;
   	# }
   	#
   	# This example uses musl because it can produce fully statically linked
   	# binaries of reasonable size.
   	#
   	# This binary does not successfully run due to bugs in obj2yaml
   	# (or possibly yaml2obj). The binary did not fully round-trip successfully.

I suspect a combination of those two would get us what we want. If that doesn't work out we can land as-is and I'll follow up on adding a test.