On Sun, Aug 28, 2011 at 7:01 AM, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
>
> It's lack of PSEUDO_SYM support. I haven't quite figured out what kind of
> code to generate for that because, frankly, I'm not completely sure what
> it's all about. ;-)
So "PSEUDO_SYM" is just a "link-time constant".
IOW, it's nothing but a pointer to an in-memory variable, and from a
code generation standpoint generating the symbol should be just about
the same as generating a constant, except rather than an actual value,
it's now a linker reference.
Of course, what complicates them is that you also need to generate the
symbol definition itself (somewhere else). In particular, the
sym->initializer points to the initializer of a symbol, and they can
be *complicated*. Generating the output for some symbols can be a
major pain in the *ss, just think about a complex structure array
initializer.
The PSEUDO_SYM you hit for the "hello world" program is trivial,
though. It's an unnamed symbol of type "char []", and it has a trivial
initializer (the string itself). So symbols can be hard to generate,
but there are simple cases.
So for a PSUEDO_SYM, you need to look up "struct symbol" for it
(pseudo->sym), which then has:
- name of the symbol (sym->ident). Of course, some symbols don't have
names, like the constant string example.
- type/size/alignment information (sym->ctype)
- initializer information (sym->initializer - which can be a really
complex expression). Of course, for external symbols - or symbols with
no initializer - this is just empty.
There's way more to symbol types in sparse than that, but apart from
the initializer expression, most of the symbol complexity has been
handled by earlier stages (ie a *lot* of the front-end of sparse is
about symbols and their types).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
