This is an archive of the discontinued LLVM Phabricator instance.

[yaml2obj][tests] Fix overly restrictive od output check
ClosedPublic

Authored by hubert.reinterpretcast on Aug 2 2019, 4:50 PM.

Details

Summary

rL364517 introduced further instances of od output checking of the kind previously corrected by rL363829. This patch corrects the issue by suppressing output of the input offset. The check remains sufficiently sensitive to test for the intended value of the specific byte since the relevant byte value is the only output we are expecting from od.

Diff Detail

Repository
rL LLVM

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2019, 4:50 PM

rL364517 introduced further instances of od output checking of the kind previously corrected by rL363829.

I leaved a comment for rL363829, it seems broke at least one of the tests.

test/tools/yaml2obj/elf-header-sh-fields.yaml
50 ↗(On Diff #213145)

Previously it tested that e_shentsize in ELF header at offset 0x72 contained value 64 (0x40) and with this YAML we changed it to 0x01.
But your version just test that somewhere in the file there are bytes 0x01 and 0x40 I think. Am I missing something?

MaskRay added a comment.EditedAug 3 2019, 7:38 AM

Can you just dump the output of od -t x1 -v -j 0x3a -N 1 %t3 on AIX? That would be more descriptive I think. It also helps us decide how to test.

rL364517 introduced further instances of od output checking of the kind previously corrected by rL363829.

I leaved a comment for rL363829, it seems broke at least one of the tests.

I've answered the question asked in rL363829.

rL364517 introduced further instances of od output checking of the kind previously corrected by rL363829.

I leaved a comment for rL363829, it seems broke at least one of the tests.

I've answered the question asked in rL363829.

We want to see the raw output... It is more descriptive than words I think.

hubert.reinterpretcast marked 2 inline comments as done.Aug 3 2019, 8:27 AM

Can you just dump the output of od -t x1 -v -j 0x3a -N 1 %t3 on AIX? That would be more descriptive I think. It also helps us decide how to test.

Here it is from AIX:

0000000  01
0000001

Here is the corresponding output from another platform (where the old check pattern worked):

0000000072    01
0000000073

In theory, it could also be this:

000000003A    01
000000003B
test/tools/yaml2obj/elf-header-sh-fields.yaml
50 ↗(On Diff #213145)

But your version just test that somewhere in the file there are bytes 0x01 and 0x40 I think.

My version tests that there is a byte whose value is 0x01 or 0x40 (for NEWSIZE and OLDSIZE, respectively) at offset 0x3a (octal 072).

MaskRay added inline comments.Aug 3 2019, 9:53 AM
test/tools/yaml2obj/elf-header-sh-fields.yaml
50 ↗(On Diff #213145)

I think it may be fine to just delete {{^[^[:blank:]]+}}. -j 0x3a -N 1 implies there is only one byte.

@hubert.reinterpretcast What does od -t x1 -v -j 0x3a -N 1 %t2 -A x (note -A x) do on AIX?

If the address is still different, I would prefer # OLDSIZE: 40 (I'm happy to change if @grimar has a different opinion)

hubert.reinterpretcast marked an inline comment as done.Aug 3 2019, 10:28 AM
hubert.reinterpretcast added inline comments.
test/tools/yaml2obj/elf-header-sh-fields.yaml
50 ↗(On Diff #213145)

Removing the {{^[^[:blank:]]+}} risks the offset matching the byte content we are checking for. It's okay to do alongside -A n, and I can update the patch to do that if it is preferred.

The address with -A x is still different on AIX:

0000000  40
0000001

Note that placing the -A x after the file operand does not change the input offset base on AIX (similar to how POSIXLY_CORRECT behaves for some implementations).

Addrew review comments: Output and check the byte values only

hubert.reinterpretcast marked 2 inline comments as done.Aug 4 2019, 5:50 AM
grimar accepted this revision.Aug 5 2019, 12:29 AM

This looks good to me. Please wait to see if Fangrui is happy too.

test/tools/yaml2obj/elf-header-sh-fields.yaml
50 ↗(On Diff #213145)

But your version just test that somewhere in the file there are bytes 0x01 and 0x40 I think.

My version tests that there is a byte whose value is 0x01 or 0x40 (for NEWSIZE and OLDSIZE, respectively) at offset 0x3a (octal 072).

Yes, sorry, I missed the -j option used here and in the committed patch.

This revision is now accepted and ready to land.Aug 5 2019, 12:29 AM
MaskRay accepted this revision.Aug 5 2019, 12:34 AM

Thanks! od -A n looks great.

hubert.reinterpretcast edited the summary of this revision. (Show Details)Aug 5 2019, 6:52 AM
This revision was automatically updated to reflect the committed changes.