RFD: Buffer handling for ASM_GENERATE_INTERNAL_LABEL

Jeff Law law@redhat.com
Sat Oct 29 03:42:00 GMT 2016


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



More information about the Gcc-patches mailing list