| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Also change xcon to have a flagset for symbols (whether it's a function,
locally defined; later: thread local, etc).
|
| |
|
|
|
|
| |
It was all over the place for temporary data structures used by
individual passes. Now there is an arena specifically for that, which is
nicer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Interned strings are used pervasively, so it's a good idea to add a
layer of type safety to differentiate them from general cstrs and avoid
potential bugs from comparing non-interned and interned strings. Not
that that's happened so far that I can remember, but it could.
I'm 90% sure it's legal to alias `struct {char c;}` pointers with `char`
pointers. This specific typedef gives type safety but with a simple
one-way `internstr -> const char *` typecast (with `&istr->c`).
Converting the other way around is more intentional: a straight up cast
`(internstr)cstr` which sticks out as unchecked and probably wrong, or
calling the intern(cstr) function, which is the right way.
|
| |
|
|
|
|
|
|
| |
For `extern int x[1];`, can use PCREL32 for &x. But for `extern int
x(int)`, must use GOTREL, when not being called directly (that's PLT).
Therefore the type of an external symbol (actually just whether it
denotes a function) matters when deciding what kind of relocation to
emit, so keep that information.
|
| | |
|
| | |
|
| | |
|
| |
|
