[PATCH] PR13475: Fix ARM SDT_V3 operand parsing

[Wade Farnsworth]

Josh Stone wrote:
> On 03/08/2012 06:53 AM, Wade Farnsworth wrote:
>> * Allow for whitespace in ARM operands containing []'s
>
> IIRC, this is sort of a latent issue on all archs.  While the compiler
> tends not to add spaces on e.g. x86, SDT probes in hand-written asm
> could very well have spaces in the arguments.  The only real separator
> we have is the '@' in each SIZE@LOCATION.  I think Roland chose '@'
> specifically for the belief that it wouldn't ever appear in the actual
> location asm string.
>
> I'm not sure if regex matching would make this easier or not, but it's
> something like:  ([+-]?\d+@[^@]+?)(\s+[+-]?\d+@[^@]+?)*
>
> Or just iteratively, find('@'), rfind(' '), split, repeat.
>
> The actual handling for the location will always be arch specific, of
> course, like dealing with ARM's [].
>
>

It appears that operand parsing on ARM fails with V2 and V1 probes as 
well, which, as I understand, don't have the SIZE@ notation.  So your 
suggestion won't work in the generic case.

With that in mind, It may be beneficial to identify where the 
non-delimiting whitespace may occur.  On ARM, I only receive 
non-delimiting whitespace after a comma.  I don't believe that any 
architecture could have a comma as the last character of a token 
(correct me if I'm wrong), so it would be simple enough to implement a 
version of tokenize() that detects a ", " sequence as non-delimiting.

Does this sound like a reasonable approach?  Would there be any other 
such exceptions that we should be detecting?

Thanks,

Wade