Issue with -printdebugline.

[Keno Fischer]

Hi Lang,

that flag is there to test the legacy behavior of not passing a
LoadedObjectInfo to DWARFContextInMemory, but instead relying on the debug
object. I see that that's not quite what it's doing though. I think the
correct fix is pass a nullptr as the second argument to
DWARFContextInMemory for `-printdebugline`. Is that compatible with the
proposed patch?

Keno

On Mon, Jul 27, 2015 at 5:58 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Keno,
>
> Is there a reason the -printdebugline test is calling getObjectForDebug()?
> Apologies - it has been a while since I looked at this, but it's causing
> some issues with the attached patch.
>
> This patch, which was requested by Eugene, changes
> LoadedObjectInfo::getSectionLoadAddress to take a SectionRef instead of a
> string section name. In theory this should be safe since LoadedObjectInfo
> is meant to provide metadata only about the object that was loaded, not the
> object returned by getObjectForDebug. In practice it's causing problems
> because -printdebugline code is mixing the two and constructing a
> DWARFContextInMemory from a debug-object and a loaded object info.
> DWARFContextInMemory tries to look up the load address of the sections of
> the debug object and gets null values back because the debug-object was
> never loaded, which leads to bogus output.
>
> My instinct is to remove -printdebugline and the call to
> getObjectForDebug(), but I wanted to check with you first: What was/is it
> meant to be testing?
>
> Cheers,
> Lang.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150727/8959d58b/attachment.html>