llvm dev - Sep 2010 - [LLVMdev] ARM/MC/ELF questions on .ARM.attributes section

Hi everyone, while looking at the ARMAsmPrinter::EmitStartofAsm
function,  I realized that what looks like singular assembler
directives (.eabi_attribute) are in fact shorthand that needs to go in
to the .ARM.attributes section in the ELF file.

1. What is the preferred method in MC to jump back to a prior section
already defined? (Or is this not supported?)

2. It looks like the "correct" way to write out these blobs in ELF  is
to add a new virtual interface to MCElfStreamer to emit the ARM
specific chunks.
I'd prefer to add a new subclass of MCELFStreamer to do this, but, it
looks like the registration mechanism for streamer does not encourage
this.
The other possibility is to add in special case code to MCELFStreamer
directly, which seems messy too. I am guessing that the latter
approach is preferred. Is this the case?

3. For the existing GNU ARM toolchain, what are the supported blobs
that go into the ARM specific sections in the ELF file? (Renato, could
you possibly shed light on  this?) I'd like to figure this out before
I attempt to fill out ARM-specific changes to the MCELFStreamer

Thanks!

-jason

On 30 September 2010 22:50, Jason Kim <jasonwkim at google.com>
wrote:
> 3. For the existing GNU ARM toolchain, what are the supported blobs
> that go into the ARM specific sections in the ELF file? (Renato, could
> you possibly shed light on  this?) I'd like to figure this out before
> I attempt to fill out ARM-specific changes to the MCELFStreamer
Hi Jason,
>From our tests, GCC doesn't understand most of them. I haven't dig
up
the source code, but we tried to pass them in different combinations
and everything gets overwritten but what GCC thinks it's right. So
far, everything but cpu and fpu gets overwritten, and the instruction
set is defined by the instructions in the assembly code, rather than
by its build attribute.

I think GCC does it mostly for compatibility, as it getting it wrong
is worse than ignoring it completely. But build attributes were not
designed to describe the standard configuration of an architecture,
but to change it according to user's necessities.

It would be great if we can get them right in LLVM, but there are
catches. We need to let the options available to all passes. The code
generation / instruction selection phases have to be in sync with all
the implications of the selected attribute, or the linking process
could blow up. Also, we need to get the possible combinations right
and show errors/warnings to the user when they get them wrong. I don't
have any case on the top of my head that could blow up but I will see
if there is any public document we can create the list of combinations
from.

About MC...

We tried to put some build attributes into the AsmWriter, but GAS
ignored it completely, and it was nothing MC related. I think we
should do it right, so we can get ASM and ELF in sync.

I'm still getting my head around MC, but I agree this should be an
ARM-only feature. Can't we override MCELFStreamer and MCAsmStreamer to
add that to the begin section of both? I think by using MCSymbols (or
maybe MCTargetExpr) attached to MCSection named ".ARM.attributes"
should do the job.

-- 
cheers,
--renato

> 1. What is the preferred method in MC to jump back to a prior section
> already defined? (Or is this not supported?)
SetSection in the MCStreamer if you really want to change the current
section, but maybe all that you need is to setSection in the Symbol?
Similar to what is done in MCELFStreamer::EmitCommonSymbol if the
binding is local.
> 2. It looks like the "correct" way to write out these blobs in
ELF  is
> to add a new virtual interface to MCElfStreamer to emit the ARM
> specific chunks.
> I'd prefer to add a new subclass of MCELFStreamer to do this, but, it
> looks like the registration mechanism for streamer does not encourage
> this.
> The other possibility is to add in special case code to MCELFStreamer
> directly, which seems messy too. I am guessing that the latter
> approach is preferred. Is this the case?
Looks like all you need to do is create a data fragment, no? If so
doing it in MCELFStreamer is the right way to do it.
> 3. For the existing GNU ARM toolchain, what are the supported blobs
> that go into the ARM specific sections in the ELF file? (Renato, could
> you possibly shed light on  this?) I'd like to figure this out before
> I attempt to fill out ARM-specific changes to the MCELFStreamer
>
> Thanks!
>
> -jason
>

Cheers,
-- 
Rafael Ávila de Espíndola

> Looks like all you need to do is create a data fragment, no? If so
> doing it in MCELFStreamer is the right way to do it.
Or, what do these attributes do for MachO? Maybe they should go to
TargetAsmBackend so that both streamers can use it.

Cheers,
-- 
Rafael Ávila de Espíndola