[Bug breakpoints/24541] Incorrect evaluation of systemtap probes due to register being signed and probe expression assuming unsigned

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24541

--- Comment #11 from Jakub Jelinek <jakub at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #10)
> (In reply to Jakub Jelinek from comment #8)
> > No, GCC does the documented thing.
> > [...] If you want to auto-detect
> > the size of the operand rather than override it, don't use any size
> > modifiers.
> 
> OK, in that case it seems like we were wrong to take the
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115 patch.  We don't want gcc
> to give information known not to match the actual data.  I wonder why we
> opted for this instead of 
> 
> # define STAP_SDT_ARG_CONSTRAINT  norq

Not really sure what you want to achieve with that.  That means the argument
can be either integer, or offsettable memory, or any GPR register, or any GPR
register ok for 8-bit values, the union of the last two sets is the third set,
so norq is the same thing as nor.  If you don't have the constraint strings
dependent on the size of the argument (not really sure how you could do it
except for requiring to use a different macro for 8-bit arguments, perhaps with
some compile time verification), then you either use nor and then need to use
some address override (w and all registers will be printed as %ax, %bx, %cx,
%dx, %si, %di, %bp, %sp or k and all registers will be printed as %eax, %ebx,
%ecx, %edx, %esi, %edi, %ebp, %esp, regardless of the size), or use noq on ia32
and then that will penalize code quite a lot, because will force all those
arguments into just %al, %bl, %cl or %dl.

>From what I see, the size is encoded in the string too, so for 8-bit arguments
you have there 1%ax, for 16-bit arguments 2%ax, for 32-bit arguments 4%ax and
for 64-bit arguments 8%ax, all that can be interpreted by stap as %al, %ax,
%eax and %eax + (%edx<<32) respectively.  So, I believe you have quite compact
representation that doesn't omit any details and is easy to interpret.

-- 
You are receiving this mail because:
You are on the CC list for the bug.