[PATCH] D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used

[Alexey Lapshin via Phabricator via llvm-commits]

avl marked an inline comment as done.
avl added inline comments.


================
Comment at: lld/ELF/InputSection.cpp:785
 void InputSection::relocateNonAlloc(uint8_t *Buf, ArrayRef<RelTy> Rels) {
+  assert(!Config->Relocatable);
+
----------------
avl wrote:
> grimar wrote:
> > avl wrote:
> > > ruiu wrote:
> > > > What does this assert mean? If you pass `-r` option to the linker, this function is not indeed called, but that's also true to many other options. Why is this option special?
> > > > 
> > > That UINT64_MAX thing should be done for only !Config->Relocatable case. 
> > > So I added this assertion to be sure that routine could not be called for other cases.
> > > If it does not fit with the design - would it be better to move that assertion closer to  
> > > Target->relocateOne(BufLoc, Type, SignExtend64<Bits>(UINT64_MAX - 1)); ?
> > We do not need this assert at all. -r output must not trigger relocations resolving.
> > It contradicts with its nature.
> > 
> > If that routine would be called for some "other cases" with -r, LLD would be just broken :)
> so if that routine could be called for some "other cases" with -r then "!Config->Relocatable" should be checked later, before 
> 
> Target->relocateOne(BufLoc, Type, SignExtend64<Bits>(UINT64_MAX - 1));
> 
> , right ? 
>If that routine would be called for some "other cases" with -r, LLD would be just broken :)

I misunderstood a bit that sentence. so you are saying that LLD would be just broken if we would be in this routine and -r specified. Then assertion looks to be correctly placed - it will signal that LLD is broken. 

But I see that LLD does not like to have that kind of assertions. I would remove it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59553/new/

https://reviews.llvm.org/D59553