This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] - Don't crash when dumping .stack_sizes and unable to find a relocation resolver.
ClosedPublic

Authored by grimar on Sep 24 2019, 6:27 AM.

Details

Summary

The crash might happen when we have either a broken or unsupported object
and trying to resolve relocations when dumping the .stack_sizes section.

For the test case I used a 32-bits ELF header and a 64-bit relocation.
In this case a null pointer is returned by the code instead of the relocation
resolver function and then we crash.

Diff Detail

Event Timeline

grimar created this revision.Sep 24 2019, 6:27 AM
grimar updated this revision to Diff 221532.Sep 24 2019, 6:33 AM
  • Rewrote the comment.
grimar updated this revision to Diff 221533.Sep 24 2019, 6:34 AM
  • The same.
jhenderson accepted this revision.Sep 25 2019, 2:10 AM

I'm beginning to think that stack-sizes.test needs breaking up into smaller tests...! This change LGTM anyway.

test/tools/llvm-readobj/stack-sizes.test
600

when we unable -> when we are unable

I'd also probably avoid unnecessarily abbreviating architecture to arch.

601

I'd probably just get rid of "valid" since a 64-bit relocation in a 32-bit object doesn't really make sense.

This revision is now accepted and ready to land.Sep 25 2019, 2:10 AM
MaskRay accepted this revision.Sep 25 2019, 2:31 AM
MaskRay added inline comments.
test/tools/llvm-readobj/stack-sizes.test
601

ELFCLASS32+EM_X86_64 can mean x32 ABI (x86_64-linux-gnux32), so not entirely "invalid"... Though it is of ELFDATA2MSB, the big-endian stuff makes it invalid.

I'm beginning to think that stack-sizes.test needs breaking up into smaller tests...!

I would probably start from splitting all the warning/error testing to stack-sizes-err.test.
They seem to take more than half (and still do not test all of the possible messages).

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 25 2019, 3:13 AM

I'm beginning to think that stack-sizes.test needs breaking up into smaller tests...!

I would probably start from splitting all the warning/error testing to stack-sizes-err.test.
They seem to take more than half (and still do not test all of the possible messages).

That would be a good start. I'd probably split the warning/error testing further into related warnings though. For example, invalid relocations could be tested in their own test.