RFC: linker placement attribute

[farcaller]

No description provided.

[mcpherrinm]

Your RFC seems to show:

#[link_placement=0xdeadbeef]
pub static mut UART0: UART;

Which differs from your proposed implementation, which is:

#[unsafe_override_address]
static t: T = 123;

I'm unclear how that version is supposed to work -- is this creating a "T" at location 123? If so, why isn't it static t: &'static T = 123;? If not, the syntax is not what I'd expect at all - T = 123; makes me think T must be a pointer type. But then how is that different from just having a pointer to that explicit location without your additions? So I must conclude this is putting a "T" at location 123, which the syntax seems very misleading for. The RFC seems much better in that respect, putting the address in an attribute.

If nothing else, the RFC should be the same as any proposed implementation.

[farcaller]

I've updated the actual implementation as per suggestion of eddyb on IRC. The original RFC proposal is a bit more tricky to maintain as it also requires modification to parser, I would rather settle with #[unsafe_override_address] static t: &'static T = 123 which is similar to having static t: *mut T = 123 as *mut T without the burden of unsafety everywhere where t is used.

My current code is using externs and expects linker script to provide the actual placement address, so #[unsafe_override_address] static t: T = 123 is closer to that. Funnily enough, implementing this patch makes my binary bigger for some reason (still going through diffs of ir), but the code gets a bit more readable as well.

I will update the RFC to match my current implementation.

[liigo]

@farcaller Why not update your implementation to match the RFC?
I like #[link_placement=0xdeadbeef] ( or #[unsafe_override_address("0xdeadbeef")] ).

[farcaller]

I've updated RFC with two alternative options.

[alexcrichton]

Thanks for the RFC! This is something that can definitely be done today, as you discovered with linker scripts or casting integers to pointers.

For now, this is something we'd like to postpone until later, although we may perhaps consider this in the future when taking a close look at how Rust fits into the embedded systems space.

Closing.