Consider this definition of ASM_GENERATE_INTERNAL_LABEL (from sp64-elf.h):
#undef ASM_GENERATE_INTERNAL_LABEL
#define ASM_GENERATE_INTERNAL_LABEL(LABEL,PREFIX,NUM) \
sprintf ((LABEL), "*.L%s%ld", (PREFIX), (long)(NUM))
And a use from assemble_static_space:
ASM_GENERATE_INTERNAL_LABEL (name, "LF", const_labelno);
For this case we can generate up to 16 bytes of data + a nul terminator.
Sadly, we only allocate 16 bytes in assemble_static_space.
Obviously it's unlikely we'll ever have a labelno that will overflow to
-2147483648 without something else breaking. So in practice this isn't
likely to ever cause a problem. But we still need to address it.
This causes 8 sparc configurations from config-list.mk to fail to build
using the trunk compiler to build the crosses.
We can obviously fix the array to be bigger here and it's a trivial
change. If we get a situation where it's out of range again, we can
detect it with the existing sprintf warnings. It's also consistent in
the sense that most callers to ASM_GENERATE_INTERNAL_LABEL use a
significantly larger buffer than assemble_static_space.
Sadly, there's a bigger issue here. Namely that the caller and the
definition of ASM_GENERATE_INTERNAL_LABEL both can include arbitrary
length text into the label name. Furthermore, the buffer is allocated
in the caller's context. It's a terrible API.
ISTM the way "out" is to change very ASM_GENERATE_INTERNAL_LABEL
implementation to use snprintf to first determine the length of the
resulting string, then allocate an appropriate amount of memory
(returning it to the caller). The caller is then changed to use the
buffer allocated by ASM_GENERATE_INTERNAL_LABEL, free-ing it when
appropriate. Major ick. We'd probably want to hook-ize the damn thing
while we're at it.
Other thoughts?
Jeff
