C2Xml - Provide a way for specifying additional attributes about reko HOT 12 CLOSED

I prefer the syntax

[[reko::register("D0",0,8)]]
[[reko::register("A1")]]
[[reko::stack]]

using namespaces to qualify the attribute and avoiding having to parse a string "0:8" when looking at byte slices.

It seems to me that specifying a byte slice (0,8) is redundant in

[[reko_partial_location(reg_D0,"0:8")]] BYTE SetTaskPri(...

since the function declaration already specifies the return type. Agree?

I should be able to write an implementation of this in a couple of days. Just want to make sure that we're in agreement on what the syntax is.

from reko.

As for syntax - yes, I realize that parametrization for other machines/environments will be much easier if register names are not hard-coded into attributes 😄

As for redundant slice..

• It's from auto-transformed code - might actually be redundant
• unlikely The function actually preserves the higher bits of D0 ?

when the support for this kind of attributes is 'in' we might steal boomerang's idea of allowing specifying full stack locations and have something like:

[[reko:memory("SP",-4)]]

from reko.

I've started implementing this on c2xml_attributes branch

from reko.

The token register is a reserved keyword in C/C++. Please switch to reg.

from reko.

Replaced 'register' with 'reg' in 52b3751

from reko.

I just checked in the C parser portion, following quite closely the C++11 spec section 7.6. In particular, the spec indicates that between [[reko::reg( and )]], any list of balanced tokens is allowed. This means that the new class CAttribute contains a list of tokens, and it is the job of the compiler/reko to interpret those tokens correctly. Right now, the interpretation is easy:
[[reko::reg( <StringConstant> )]] for register declarations
[[reko::mem( <StringConstant> <Comma> (<Minus>) <Integer> )]] for memory declarations

from reko.

Feature implemented in master. Now all we have to do is make reko recognize the services as A6-based. That's a different issue . Please verify that you can build and run any tests you think appropriate, then close.

from reko.

Awesome 😄

I've fixed a few problems in the exec_functions header, but there is one feature missing -> handling the bit selection in reg attribute.

• I could remove the bit selection from the header, but that will remove some of the data decompilation might find useful ?
• Or I might extended attr handling to preserve the bit-range in Register_v1 class ?

from reko.

Leave the bits in the file; the current implementation of [[reko::reg]] will just ignore them. Bit slice handling is should be handled generically by ApplicationBuilder.

Reko has an internal issue, which is the representation of data in registers which may be smaller than the register size itself. On the x86 we are lucky because the processor has aliases for the smaller pieces of the register (rax, eax, ax, al) but many other architectures like m68k and PowerPC don't. I expect I will have to take a look at ApplicationBuilder and its related classes to see what can be done.

In the meantime, can we consider this issue resolved? Attributes can now be specified, and we can add more, like [[noreturn]], which is a standard attribute that indicates that procedures don't return (think exit(int n)).

from reko.

This fails

void f([[reko::reg("D0",0,4)]] int intNum);

with:

System.FormatException: [[reko::reg]] attribute expects a register name.

since GetArgumentKindFromAttributes

if (attr.Tokens.Count != 1 || attr.Tokens[0].Type != CTokenType.StringLiteral)
    throw new FormatException("[[reko::reg]] attribute expects a register name.");
kind = new Register_v1 { Name = (string)attr.Tokens[0].Value };

from reko.

Fixed now.

from reko.

The file is parsed correctly now

from reko.