[llvm-commits] [PATCH] Review request - MCJIT GDB source level debugging and runtime loader improvements

[Kaylor, Andrew]

I could split it between the runtime loader improvements and the debugger integration, which are each roughly half the patch.  I'll start working on that, but I would greatly appreciate the efforts of anyone willing to start looking at it in the mean time.

-Andy

-----Original Message-----
From: Eric Christopher [mailto:echristo at apple.com] 
Sent: Wednesday, March 28, 2012 2:23 PM
To: Kaylor, Andrew
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH] Review request - MCJIT GDB source level debugging and runtime loader improvements

Is it at all possible to break this up into incremental patches and commits?

-eric

On Mar 28, 2012, at 2:20 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> The attached files are a contingent patch to improve MCJIT runtime loading and implement source-level GDB JIT debugging integration.  This patch is based on an earlier revision of the LLVM trunk code (r153221).  That revision has been temporarily reverted, but I expect that it will be re-commited soon.  I will submit a new patch when that code is in trunk, but I wanted to get this patch started in the review process as soon as possible because of its size.
>  
> I have separated the patch into two files.  The first file contains the actual implementation details.  The second file contains some new test files and a minor change to an existing file.  The 'new' test files are actually just duplicates of existing tests that are being copied to the MCJIT directory so that these tests will be exercised with the MCJIT engine.
>  
> The primary patch implements new handling of zero-initialized sections, virtual sections and common symbols and prevents the loading of sections which are not required for execution such as debug information.  By "loading" here I mean the process of allocating memory for the section, copying its contents into that memory and performing applicable relocations.  These improvements required the addition of new functions in the ObjectFile class and its subclasses to test various attributes of a section.  Because I am not familiar with all the details of the MachO and COFF formats, I have used default implementations in some places.  This default code should produce correct results, but it may not be the most optimized behavior possible.  I believe I am correctly handling common symbols for both ELF and MachO formats.
>  
> The GDB JIT debugging integration support works by registering a "loaded" object image with a pre-defined function that GDB will monitor if GDB is attached.  I have only implemented GDB integration support for ELF, but I think it should be possible to add MachO support if anyone is interested in doing so.  This integration requires GDB version 7.0 or newer.
>  
> To get GDB to correctly recognize the registered image, the addresses in code and data section headers needed to be updated to reflect the address at which these sections were loaded into process memory.  This required the introduction of a level of abstraction that lets me create a subclass of ELFObjectFile to update the section headers in the object file image emitted by the code generator.  I am using a new abstraction class, ObjectImage, to continue to allow the format-independent code to be abstracted, while providing a convenient place to introduce the new ELFObjectFile subclass and adding methods to update section and symbol addresses during the loading process.  The default implementation of ObjectImage aggregates ObjectFile and provides empty stubs for the update functions so that it behaves exactly as ObjectFile did in the code revision on which my changes are based.
>  
> I've tested this code on 32- and 64-bit Linux systems and on a 64-bit Mac system.  In my testing, all execution tests pass.
>  
> Thanks in advance for your reviews and feedback.
>  
> -Andy
> <01-gdb-integration.patch><02-gdb-integration-tests.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits