[PATCH] D56453: Modify InputSectionBase::getLocation to add section and offset to every location string.
Rui Ueyama via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 9 15:45:41 PST 2019
ruiu accepted this revision.
ruiu added a comment.
This revision is now accepted and ready to land.
LGTM
================
Comment at: ELF/InputSection.cpp:310
if (Defined *D = getEnclosingFunction<ELFT>(Offset))
- return SrcFile + ":(function " + toString(*D) + ")";
+ return SrcFile + ":(function " + toString(*D) + ": " + SecAndOffset + ")";
----------------
sfertile wrote:
> ruiu wrote:
> > I think that the idea here is that a function name and an object file name uniquely identifies an error location. A section name and an offset is the last resort if there's no other information we can display.
> >
> > Did you find it useful to print out a section name and an offset in addition to function name? If so, in what situation?
> >
> The motivation for this change comes from a range-check error message I get from a compiler generated file. Since the compiler adds the filename we get a message that look roughly like this:
> ` test.c:(function foo): relocation R_PPC64_ADDR16_DS out of range: 32808 is not in [-32768, 32767]`
>
> The problem is that foo could potentially have dozens of `R_PPC64_TOC16_DS` relocations. By adding the section and offset I can pinpoint exactly which relocation is overflowing/underflowing immediately. The same benefits holds for the `checkAlignment` diagnostics.
>
> I agree for some of the error messages the extra info holds no value. For example the diagnostic for split-stack prologue adjust failure is completely characterized by the file and the function. I think I would prefer to keep the extra info even in this case so that the diagnostics are consistent and we don't need to be able to generate 2 slightly different formattings but I don't feel to strongly either way.
>
>
I'm fine with extra info as long as you find that is useful. At least that shouldn't hurt anyone. Thank you for the explanation!
Repository:
rLLD LLVM Linker
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56453/new/
https://reviews.llvm.org/D56453
More information about the llvm-commits
mailing list