Fix parsing of "archive:mem" input section description pattern
#681
Conversation
parth-07
force-pushed
the
ArchiveMemPattern
branch
2 times, most recently
from
11b25c9 to
90f1426
Compare
This commit fixes the parsing / interpretation of `"archive:mem"` file pattern. Previously, it was getting incorrectly stored because we were not properly handling quotes when a single quoted token in the linker script (`"archive:member"`) is stored as two separate patterns in the linker implementation. Resolves qualcomm#680 Signed-off-by: Parth Arora <[email protected]>
parth-07
force-pushed
the
ArchiveMemPattern
branch
from
90f1426 to
19a4ea3
Compare
| // We cannot store the original quote information because we represent | ||
| // the single token "archive:mem" in the linker script as two separate | ||
| // patterns in the linker codebase. | ||
| Tok = unquote(Tok); |
There was a problem hiding this comment.
Should we use createParserStr to preserve the property that the input token had a quote.
The map file might not show information about quotes from the linker script or the linker script generator too.
There was a problem hiding this comment.
createParserStr alone would not be helpful here. We do use createParserStr within createAndRegisterWildcardPattern. The issue is that a single quoted token ("archive:mem") is stored as two separate tokens -- archive file pattern and member pattern -- in the linker codebase. It would be incorrect to store both archive file pattern and the member pattern with quotes if the original combined pattern was with quotes because "archive":"mem" would be interpreted differently from "archive:mem".
2 participants
This commit fixes the parsing / interpretation of
"archive:mem"file pattern. Previously, it was getting incorrectly stored because we were not properly handling quotes when a single quoted token in the linker script ("archive:member") is stored as two separate patterns in the linker implementation.Resolves #680