Issue with -printdebugline.

[Lang Hames]

Thanks for the catch Eugene. Fixed in r243542.

Cheers,
Lang.

On Tue, Jul 28, 2015 at 1:34 PM, Eugene Rozenfeld <
Eugene.Rozenfeld at microsoft.com> wrote:

>  Hi Lang,
>
>
>
> Thank you for doing this!
>
> A couple of comment nits I noticed:
>
> 1.       In DIContext.h the comment for getSectionLoadAddress wasn’t
> updated:
>
>         /// Obtain the Load Address of a section by Name.
>
> 2.       Typo in the same comments: needs to be consistent à need to be
> consistent
>
>
>
> Eugene
>
>
>
> *From:* Lang Hames [mailto:lhames at gmail.com]
> *Sent:* Tuesday, July 28, 2015 10:54 AM
> *To:* Keno Fischer <kfischer at college.harvard.edu>
> *Cc:* Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com>; Commit Messages
> and Patches for LLVM <llvm-commits at cs.uiuc.edu>
> *Subject:* Re: Issue with -printdebugline.
>
>
>
> 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/20150729/f383958e/attachment.html>