This is an archive of the discontinued LLVM Phabricator instance.

Segfault in AArch64 backend with -g and -mbig-endian
ClosedPublic

Authored by olista01 on Aug 12 2014, 10:36 AM.

Details

Reviewers
rengolin
echristo
Summary

Fix a null pointer dereference when trying to swap the endianness of fixups in the .eh_frame section in the AArch64 backend.

Diff Detail

Event Timeline

olista01 updated this revision to Diff 12404.Aug 12 2014, 10:36 AM
olista01 retitled this revision from to Segfault in AArch64 backend with -g and -mbig-endian.
olista01 updated this object.
olista01 edited the test plan for this revision. (Show Details)
olista01 set the repository for this revision to rL LLVM.
olista01 added a subscriber: Unknown Object (MLST).
echristo added inline comments.
lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

Fixup to a null section? How's that happen?

olista01 added inline comments.Aug 14 2014, 1:38 AM
lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

This is the section associated with the value to put into the fixup location, not the section containing the fixup location. This can be null if:

  • It is a symbol which is not defined by this translation unit
  • It is the difference between two temporary symbols, for example to find the length of a debug data structure.
rengolin added inline comments.
lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

Is this a null section or not an ELF section? Your check seems to imply the latter, while I believe it's the former.

In that case, this would be better fixed in the caller, since the result of a null section means you're applying a fixup to a null section and propagating the error.

olista01 added inline comments.Aug 26 2014, 9:26 AM
lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

MCExpr::FindAssociatedSection can return nullptr when the expression is a reference to a symbol not defined in this translation unit, so we do have to be able to handle nullptr here without it being an error.

rengolin added inline comments.Sep 4 2014, 3:53 AM
lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

Right, so, to reiterate Eric's idea:

A fixup having a location that:

  1. was not defined in this unit doesn't make much sense
  2. is the result of removed temporary value, should have been removed when the values got out of context

If the problem here is 1, than we need to know why we're trying to reach non-existent sections in the first place. If the problem is 2, we need to know how to delete the fixups related to just deleted values, so we don't come here with null pointers.

But, that's not necessarily part of this patch, since FindAssociatedSection() does return nullptr on those cases.

I'll defer to Eric to approve this.

rengolin accepted this revision.Sep 17 2014, 5:06 PM
rengolin added a reviewer: rengolin.

Oliver,

I think there are two things, and your patch fixes one that needs fixing, while there is another that might not need fixing.

The patch looks good to me, feel free to commit. The ELF section needs further analysis, but that's nothing to do with this patch.

Sorry for the delay.

cheers,
--renato

This revision is now accepted and ready to land.Sep 17 2014, 5:06 PM
echristo edited edge metadata.Sep 17 2014, 5:12 PM

I'm not sure we should paper over this possible problem.

I haven't had a chance to look into the comment here:

"A fixup having a location that:

was not defined in this unit doesn't make much sense
is the result of removed temporary value, should have been removed when the values got out of context"

and Oliver hasn't replied yet either. I do think it's relevant to this patch.

lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
538

Ah right. Thanks.

So, in this case, the revert need only to happen if the section is .eh_frame. If the section is empty, it's not .eh_frame and the local logic is not wrong.

That's not saying there isn't a problem and that it doesn't need fixing, it just says that this is not the point of *this* patch. What'd be the problem of fixing this and creating a new bug for the empty section? What guarantees that this is the only case where the section is empty? I believe that the right thing to do is to fill the section code with asserts, so we can pinpoint the origin of the problem. But none of that would make this fix wrong in the future.

Furthermore, the function does return null when it doesn't find the section, so if that was really wrong it should assert in the first place. I don't understand what the problem is in this case, can you elaborate?

olista01 closed this revision.Sep 23 2014, 8:49 AM

I have committed this as revision 218311, and I will find some time later this week to check for a deeper problem.

Thanks Oliver.

I do agree with Eric that we must look into this problem ASAP. Have you created a bug for it? Please copy both of us on it, so we're aware of your progress.

cheers,
--renato