[llvm-dev] Building an array in a section from multiple object files
Dean Michael Berris via llvm-dev
llvm-dev at lists.llvm.org
Sun Jun 26 21:30:40 PDT 2016
Just to close this out, I've updated http://reviews.llvm.org/D19904 to use
named ELF groups per-function, and have the runtime library use
__start_xray_instr_map and __stop_xray_instr_map as weak symbols from the
C++ side. I've sent a patch to make creating these COMDAT/Group sections
easier when lowering through the MCStreamer interface (
http://reviews.llvm.org/D21743).
Cheers
On Fri, Jun 24, 2016 at 4:23 AM Dean Michael Berris <dberris at google.com>
wrote:
> Awesome, thanks Peter!
>
> Cheers
>
> On Thu, Jun 23, 2016 at 10:35 AM Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>
>> If you give your section a valid C identifier name, i.e. something like
>> "xray_instr_map" (no period), the linker will synthesize symbols named
>> "__start_xray_instr_map" and "__stop_xray_instr_map", which will point to
>> the start and end of the combined section.
>>
>> Peter
>>
>> On Thu, Jun 23, 2016 at 10:26 AM, Dean Michael Berris via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> As part of working on XRay, I'm trying to accomplish the following:
>>> create a section that contains an array of entries pertaining to the
>>> instrumentation map (nop sleds) in an object file, and have those merged
>>> into a single section in the final binary where the contents are
>>> concatenated. The trick though is I'd like to be able to reference the
>>> whole array with a single symbol (or two, one to mark the start and the
>>> other to mark the end). I'm trying to get this to work initially on x86 and
>>> Linux (ELF).
>>>
>>> What I've got currently in http://reviews.llvm.org/D19904 creates this
>>> section (.xray_instr_map) and defines two globals in that section named
>>> "__xray_instr_map" and "__xray_instr_map_end". The problem inevitably with
>>> this approach is that having multiple object files have these definitions
>>> cause issues with multiple definition violations at link time.
>>>
>>> I *think* the solution involves having COMDAT sections per-function that
>>> has the instrumentation points, then have those concatenated into a single
>>> .xray_instr_map section.
>>>
>>> What I'm not sure about is how to define the "__xray_instr_map" and
>>> "__xray_instr_map" symbols such that they refer to the contents of the
>>> section in the final binary.
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>>
>> --
>> --
>> Peter
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160627/858f881a/attachment.html>
More information about the llvm-dev
mailing list