[LLVMdev] Address space information dropped

[Ivan Llopard]

On 08/05/2012 02:10, Joerg Sonnenberger wrote:
> On Tue, May 08, 2012 at 12:57:15AM +0200, Ivan Llopard wrote:
>> Le 07/05/2012 17:15, Joerg Sonnenberger a écrit :
>>> On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote:
>>>> Thanks for your quick response Joerg.
>>>>
>>>> We have a very small test case where there is global array and its
>>>> address space attribute specified like in the following code
>>>>
>>>> const int __attribute__((address_space(256))) fangle[13] =
>>>>    {2341, 4681, 7022, 9362, 11703, 1403,16384,
>>>>     18725, 21065, 23406, 25746, 28087, 30427};
>>>>
>>>> I need to put its initializer in another memory because it has a
>>>> different address space and I wanted to pass this information
>>>> through a target-depend asm directive.
>>>> At the moment, I've overridden EmitGlobalVariable() from AsmPrinter
>>>> because I didn't see any other spot to put this special directive.
>>> Have you thought about always tagging such global variables with
>>> __attribute__((section("fancyaddresspace"))) as well? That seems to be
>>> the sanest way I can think of.
>>
>> Yes, but it seems a little odd to me. Is it correct to assume that
>> different sections imply different address spaces ?
>> I rather wanted to have a special asm directive on the top of
>> section definitions to switch between memories following an
>> identical section layout for both of them.
>
> Let's take a step back. "address space" is a type modifier like __thread.
>> From codegen perspective, primarily changes the way access is done.
> Variable declaration requires obtaining some pointer value and possibly
> initialising it. For __thread, this is done by putting the object into
> .tdata or .tbss sections and letting the linker do the rest. That is:
> - merging corresponding sections
> - ensuring that (in cooperation with the runtime linker and thread
> library) initialisation happens as needed
> - correct relocation records are created.

Thanks for your clear explanation.

>
> What needs to happen in your use case is essentially the same. You don't
> need some of the complications of __thread, but the idea is:
> (1) Put the objects into a separate section.
> (2) Make sure that the section ends up in your memory image by using an
> appropiate linker script.
> (3) Make sure that the section is relocated to a fixed location,
> representing the offset in the address space.
> (4) Add startup code to copy the content of the executable to the
> address space.
>
> At least for an ELF target or comparable object format, you don't need
> special assembler support.

Looks like a cleaner solution, thanks!

I know MCELFStreamer has default sections for every kind of data to 
stream out. I thought I could save some efforts if I reused them, and 
its section flags also, avoiding the specification of additional ones.
Nevertheless, it's clearly not a linker-friendly solution...

Ivan

>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev