This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Don't segfault when accessing location counter inside MEMORY command.
ClosedPublic

Authored by grimar on Aug 1 2017, 4:22 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.Aug 1 2017, 4:22 AM
ruiu edited edge metadata.Aug 1 2017, 5:55 AM

CurAddressState is used at various places in this file, and it doesn't seem like this is the only place that you can trigger a null pointer access. Are you sure that this fix is enough?

grimar added a comment.Aug 1 2017, 6:11 AM
In D36138#827316, @ruiu wrote:

CurAddressState is used at various places in this file, and it doesn't seem like this is the only place that you can trigger a null pointer access. Are you sure that this fix is enough?

I am trying to fix issues I know about + look around for similar cases. This issue happened because CurAddressState was accessed before processing sections commands,
where it is assigned initially. At this moment I do not know about other similar cases which can trigger null pointer access to CurAddressState.
Though it is probably can be possible, do you know any ?

I think we can go step by step probably and see if we need some generic helper or something if see another cases with CurAddressState.

I don't know whether it helps much at all, but here goes. The idea behind CurAddressState was to make sure we kept together all the information that needed to be cleared between successive calls to assignAddresses(). The two places I could spot from our existing test cases was that processCommands() and assignAddresses() that traversed the command list and evaluated expressions so that is where I thought that getSymbolValue() would actually be evaluated.

I think that this one must come from readMemoryAssignment( ) in ScriptParser as it calls readExpr()().getValue() and if readExpr happens to return "." then we will evaluate "." which to my understanding isn't allowed as the manual says "The expression must evaluate to a constant before memory allocation is performed, which means that you may not use any section relative symbols."

The places that could go wrong and access a Null Pointer are I think restricted to where .getValue() is called on an expression containing "." outside the context of processCommands() or assignAddresses(), which I believe is where the ScriptParser is expecting a constant. As such I think the fix should at least give an error message, and if you are looking for more test cases then using "." in areas where the parser is expecting a constant will be a good place to look.

For reference CurAddressState was put in under D34345, although comments will probably need to be found on the list as I don't think that they automatically get added to Phab..

ruiu accepted this revision.Aug 16 2017, 4:11 PM

LGTM

test/ELF/linkerscript/memory-err.s
1 ↗(On Diff #109079)

Rename memory-error.s (you don't need to save two characters in filename.)

This revision is now accepted and ready to land.Aug 16 2017, 4:11 PM
grimar added inline comments.Aug 17 2017, 12:40 AM
test/ELF/linkerscript/memory-err.s
1 ↗(On Diff #109079)

Ok, though we have many tests with both ways of naming atm.

grimar added inline comments.Aug 17 2017, 1:01 AM
test/ELF/linkerscript/memory-err.s
1 ↗(On Diff #109079)

Ah and we already have memory-err.s one committed.
I'll leave name unchanged for commit.

Should we rename all *-err.s to *-error.s at once then ?

This revision was automatically updated to reflect the committed changes.