Issue with -printdebugline.

[Lang Hames]

Hi Keno,

Thanks for that. After a little tweaking (I had made the same mistake of
referencing the wrong object in my ELF getObjectForDebug code) that works
perfectly. Committed in r243456.

- Lang.


On Mon, Jul 27, 2015 at 3:24 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> 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/20150728/a063c2ef/attachment.html>