This patch shows both file and line for linker script errors, including:
- Errors occurred in lexer (ScriptParserBase::tokenize)
- Errors occurred in included files (via INCLUDE directive)
See updated test cases in diagnostics.s
Differential D26795
[ELF] Better error reporting for linker scripts evgeny777 on Nov 17 2016, 6:07 AM. Authored by
Details This patch shows both file and line for linker script errors, including:
See updated test cases in diagnostics.s
Diff Detail Event Timeline
Comment Actions I wonder if we can remove INCLUDE directive from the linker script. I added that without thinking about it, but I've never seen any use of it. Linker scripts that add other linker scripts usually add that with INPUT() directive. Comment Actions This is a question, I cannot answer :). You can't replace INCLUDE with INPUT and vice versa, but if you remove it then this patch will be much simpler. Comment Actions Looks like I found few projects which use INCLUDE directive: http://libopencm3.org/wiki/Run_From_RAM The last one seems to be a chromebook boot loader: it includes script files in auto-generated linker script ldscript.ld I don't know how important is to support those in lld, but please confirm that you want to get rid of INCLUDE Comment Actions I'm not speaking for Google, but Chromebook boot loader is probably a large user we can't ignore, so I'm inclined to not remove INCLUDE. I'll review your patch tomorrow.
Comment Actions
You also have to store file name for each token and I think this is too much. How about storing a vector of MemoryBufferRef instead of 'Input' in ScriptParserBase? Please take a look at the updated diff. Comment Actions Moved file management to ScriptParserBase. Now errors in version scripts and dynamic lists are handled in a new way as well Comment Actions It's much better than before, but I still think that we could do more by using parallel arrays. We want to maintain four tuples (filename, line content, line number, column number) for each token, and all of them are small (they are intetgers and StringRefs). So I think it's not going to be too much. That being said, we can do that later. It is indeed a very good improvement. Thanks! LGTM
|
That is pretty much what a MemomryBufferRef is. Can't you store that instead of the std::pair?