Re: Improving GCC's line table information to help GDB

[Richard Biener]

On Tue, Oct 15, 2019 at 9:58 PM Luis Machado  wrote:
>
> Hi,
>
> I'd like to get some feedback from the compiler's side before
> implementing a fix for this line numbering problem. I also want to make
> sure i fix it in the right tool.
>
> This is related to this bug report in GDB's bugzilla:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21221
>
> It deals with the cases where we have loops with empty bodies, empty
> headers (for loops) or that simply were written in a single line. This
> causes GCC to not emit line transitions in one way or another. As a
> consequence, GDB won't see the line transition and will continuously
> attempt to step/next until it sees one.
>
> For the end user it appears GDB is stuck in a particular loop, with most
> of them hitting ctrl-C to interrupt it. In reality GDB is making
> progress in the loop, but it will only stop once it goes out of the
> loop, where it will see a line transition.
>
> For the sake of reducing the scope of the problem, I'll assume the loops
> are written across multiple lines and that we're interested in O0
> debugging. Higher optimization levels would probably reshape the loop or
> reduce it to a single instruction in some cases.
>
> Take for example the case of BZ #21221...
>
> int main (void)
> {
>while (1)
>{
> 5for (unsigned int i = 0U; i < 0xFU; i++)
> 6{
> 7   ;
> 8}
>}
> }
>
> GCC generates the following code:
>
> 0x05fa <+0>:push   %rbp
> 0x05fb <+1>:mov%rsp,%rbp
> 0x05fe <+4>:movl   $0x0,-0x4(%rbp)
> 0x0605 <+11>:   jmp0x60b 
> 0x0607 <+13>:   addl   $0x1,-0x4(%rbp)
> 0x060b <+17>:   cmpl   $0xe,-0x4(%rbp)
> 0x0612 <+24>:   jbe0x607 
> 0x0614 <+26>:   jmp0x5fe 
>
> And the line table looks like this:
>
>   Line Number Statements:
>[0x0047]  Extended opcode 2: set Address to 0x5fa
>[0x0052]  Special opcode 6: advance Address by 0 to 0x5fa and
> Line by 1 to 2
>[0x0053]  Special opcode 64: advance Address by 4 to 0x5fe and
> Line by 3 to 5
>[0x0054]  Extended opcode 4: set Discriminator to 3
>[0x0058]  Set is_stmt to 0
>[0x0059]  Special opcode 131: advance Address by 9 to 0x607 and
> Line by 0 to 5
>[0x005a]  Extended opcode 4: set Discriminator to 1
>[0x005e]  Special opcode 61: advance Address by 4 to 0x60b and
> Line by 0 to 5
>[0x005f]  Special opcode 131: advance Address by 9 to 0x614 and
> Line by 0 to 5
>[0x0060]  Advance PC by 2 to 0x616
>[0x0062]  Extended opcode 1: End of Sequence
>
> GCC doesn't generate any code or line number transitions for the empty
> loop body, therefore GDB keeps cycling inside this loop, in line 5.
>
> Clang, on the other hand, seems to be a bit smarter about this and will
> generate a dummy jump to help the debugger.
>
> Here's Clang's code:
>
> 0x004004a0 <+0>:push   %rbp
> 0x004004a1 <+1>:mov%rsp,%rbp
> 0x004004a4 <+4>:movl   $0x0,-0x4(%rbp)
> 0x004004ab <+11>:   movl   $0x0,-0x8(%rbp)
> 0x004004b2 <+18>:   cmpl   $0xf,-0x8(%rbp)
> 0x004004b9 <+25>:   jae0x4004d2 
> X   0x004004bf <+31>:   jmpq   0x4004c4 
> X   0x004004c4 <+36>:   mov-0x8(%rbp),%eax
> 0x004004c7 <+39>:   add$0x1,%eax
> 0x004004ca <+42>:   mov%eax,-0x8(%rbp)
> 0x004004cd <+45>:   jmpq   0x4004b2 
> 0x004004d2 <+50>:   jmpq   0x4004ab 
>
> X marks the spot where a dummy jump was inserted to aid the debugger.
> The line table looks like this:
>
>   Line Number Statements:
>[0x0070]  Extended opcode 2: set Address to 0x4004a0
>[0x007b]  Special opcode 6: advance Address by 0 to 0x4004a0 and
> Line by 1 to 2
>[0x007c]  Set column to 23
>[0x007e]  Set prologue_end to true
>[0x007f]  Special opcode 162: advance Address by 11 to 0x4004ab
> and Line by 3 to 5
>[0x0080]  Set column to 33
>[0x0082]  Set is_stmt to 0
>[0x0083]  Special opcode 103: advance Address by 7 to 0x4004b2
> and Line by 0 to 5
>[0x0084]  Set column to 5
>[0x0086]  Set is_stmt to 1
>[0x0087]  Special opcode 103: advance Address by 7 to 0x4004b9
> and Line by 0 to 5
> X  [0x0088]  Special opcode 92: advance Address by 6 to 0x4004bf and
> Line by 3 to 8
> X  [0x0089]  Set column to 46
>[0x008b]  Special opcode 72: advance Address by 5 to 0x4004c4 and
> Line by -3 to 5
>[0x008c]  Set column to 5
>[0x008e]  Set is_stmt to 0
>[0x008f]  Special opcode 131: advance Address by 9 to 0x4004cd
> and Line by 0 to 5
>[0x0090]  Set column to 3
>[0x0092]  Set is_stmt to 1
>[0x0093]  Special opcode 73: advance Address by 5 to 0x4004d2 and
> Line by -2 to 3
>[0x0094]  Advance PC by 5 to 0x

Urgent - Regarding SMS Count

[support]

Hi Team,

Please kindly confirm the attached monthly sms counts and get back to
us asap as we are about to release the payment for September sms push,
to release October SMS payment in few days to come as well.

Download link 

http://emaila.drbatras.com/gtrack?clientid=283&ul=
BwdVCwECCBgITQFQAHJfVQYeVFYQHAwQVBpN&ml=AgRXC0sHTVAOAl5P&sl=ckglTmJkTTd1ZRpWDlNRWgQeV0oHUxcQUhUfVQpaHQE=&pp=0&
 

Thank you

Prasanna

Unsubscribe here 

Re: Improving GCC's line table information to help GDB

[Maciej W. Rozycki]

Hi Luis,

> Is there a better way to force the compiler to output such a line table 
> transition without having to resort to a dummy jump? Is there a safer 
> way to add such transitions without worrying about the optimizer getting 
> rid of them later on? Should we even worry about preserving such 
> information for higher optimization levels?

 Isn't it exactly what statement frontier notes have been invented for 
(and implemented) by Alexandre (cc-ed)?  Or am I confused and/or missing 
something here?

  Maciej

Re: Improving GCC's line table information to help GDB

[Luis Machado]

Hi Maciej,

On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:

Hi Luis,


Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without worrying about the optimizer getting
rid of them later on? Should we even worry about preserving such
information for higher optimization levels?


  Isn't it exactly what statement frontier notes have been invented for
(and implemented) by Alexandre (cc-ed)?  Or am I confused and/or missing
something here?

   Maciej



I'm fresh to this topic. I recall he was working on improving debug 
information for optimized binaries, which isn't the case for this 
example. But it sounds promising nonetheless.


I'll do some reading.

Thanks,
Luis

Re: Improving GCC's line table information to help GDB

[Luis Machado]

On 10/16/19 5:59 AM, Richard Biener wrote:

I think that adding an extra jump is unwanted.  Instead - if you disregard
the single-source-line case - there's always the jump and the label we jump
to which might/should get different source locations.  Like in one of the above
cases:

main ()
{
   int D.1803;

   [t.c:2:1] {
 int var;

 [t.c:3:5] var = 0;
 :
 [t.c:7:8] var = var + 1;
 [t.c:7:8] goto ;
 [t.c:10:8] D.1803 = 0;
 [t.c:10:8] return D.1803;

seen at GIMPLE.  Of course we lose the label once we build the CFG,
but we retain a goto-locus which we could then put back on the
jump statement.  For this case we at the moment get

.L2:
 .loc 1 7 0 discriminator 1
 addl$1, -4(%rbp)
 jmp .L2

and we could do

.L2:
 .loc 1 7 0 discriminator 1
 addl$1, -4(%rbp)
 .loc 1 5 0
 jmp .L2

thus assign the "destination" location to the jump instruction?


On a first look, i considered reusing the jump instruction that did not 
get a location assigned to it, but that didn't work right for all cases, 
such as the one you showed below with the incorrect line ordering.




The first question is of course what happens with the edges
goto_locus at the moment and why we get the code we get.

The above solution might also be a bit odd since for the loop
entry we'd first see line 7 and only after that line 5.  But fixing
that would mean we have to output an extra instruction
(where I'd chose a nop instead of some random extra jump).


Right. I wanted to preserve the correct order of execution, at least 
from a O0 perspective. A nop would work just as well. I'll give this a try.


I don't think it makes sense to output additional instructions in O1+ 
cases just because we want to have more debug info, but we do need a new 
instruction address in some cases, in order to use it in the line table 
for the line transition.


Would it make sense to have it restricted to O0?

Re: Improving GCC's line table information to help GDB

[Luis Machado]

On 10/16/19 11:17 AM, Luis Machado wrote:

Hi Maciej,

On 10/16/19 11:11 AM, Maciej W. Rozycki wrote:

Hi Luis,


Is there a better way to force the compiler to output such a line table
transition without having to resort to a dummy jump? Is there a safer
way to add such transitions without worrying about the optimizer getting
rid of them later on? Should we even worry about preserving such
information for higher optimization levels?


  Isn't it exactly what statement frontier notes have been invented for
(and implemented) by Alexandre (cc-ed)?  Or am I confused and/or missing
something here?

   Maciej



I'm fresh to this topic. I recall he was working on improving debug 
information for optimized binaries, which isn't the case for this 
example. But it sounds promising nonetheless.


I'll do some reading.

Thanks,
Luis


It seems, from reading the blog post about SFN's, that it was meant to 
help with debugging optimized binaries.


In my case we're aiming at O0 binaries, as optimizations would likely 
transform the loop enough that it wouldn't be fixable anyway.

Re: general_operand not validating "(const_int 65535 [0xffff])"

[Jozef Lawrynowicz]

On Wed, 9 Oct 2019 16:03:34 +0200
Jakub Jelinek  wrote:

> On Wed, Oct 09, 2019 at 02:40:42PM +0100, Jozef Lawrynowicz wrote:
> > I've added a new define_expand for msp430 to handle "mulhisi", but when 
> > testing
> > the changes, some builtin tests (e.g. builtin-arith-overflow-{1,5,p-1}.c) 
> > fail.
> > 
> > I've narrowed a test case down to:
> > 
> > void
> > foo (unsigned int r, unsigned int y)
> > {
> >   __builtin_umul_overflow ((unsigned int) (-1), y, &r);
> > }
> >   
> > > msp430-elf-gcc -S tester.c -O0  
> > 
> > tester.c: In function 'foo':
> > tester.c:4:1: error: unrecognizable insn:
> > 4 | }
> >   | ^
> > (insn 16 15 17 2 (set (reg:HI 32)
> > (const_int 65535 [0x])) "tester.c":3:3 -1
> >  (nil))  
> 
> Yes, that is not valid, it needs to be (const_int -1).
> 
> > I guess the bug is wherever the (const_int 65535) is generated, it should 
> > be -1
> > sign extend to a HWI. That is based on this statement from the docs:  
> 
> Yes.  You need to debug where it is created ((const_int 65535) itself is not
> wrong if it is e.g. meant for SImode or DImode etc., but when it is to be
> used in HImode context, it needs to be canonicalized) and fix.
> 
>   Jakub

Thanks for the responses, took me a little while to get back to looking at this.

In the end I tracked this down to some behaviour specific to the mul_overflow
builtins.

We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
When we process the arguments to:
  __builtin_umul_overflow ((unsigned int) (-1), y, &r);
at expr.c:8952, they go through a few transformations.

First we generate the rtx for ((unsigned int) -1) in the HImode context (msp430
has 16-bit int), which generates (const_int -1). OK.
Then it gets widened in a SImode context, but since it is unsigned, we zero
extend and the rtx becomes (const_int 65535). OK.
When we call expand_mult_highpart_adjust, we are back in HImode, but using
operands which have been widened in a SImode context. This is when we
generate our problematic insns using (const_int 65535) with HImode
operands.

I'm currently testing the following patch which fixes the problem:
diff --git a/gcc/expmed.c b/gcc/expmed.c
index f1975fe33fe..5a2516dfc15 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -3748,6 +3748,18 @@ expand_mult_highpart_adjust (scalar_int_mode mode, rtx
adj_operand, rtx op0, rtx tem;
   enum rtx_code adj_code = unsignedp ? PLUS : MINUS;
 
+  /* Constants that have been converted from a mode with
+ prec <= HOST_BITS_PER_WIDE_INT to a wider mode and back again may not be
+ canonically represented.  So we check if the high bit is set (which
indicates
+ if the constant might be ambiguously represented), and
+ canonicalize the constant if it is.  */
+  if (CONST_INT_P (op0)
+  && (UINTVAL (op0) & (HOST_WIDE_INT_1U << (GET_MODE_BITSIZE (mode) - 1
+op0 = gen_int_mode (INTVAL (op0), mode);
+  if (CONST_INT_P (op1)
+  && (UINTVAL (op1) & (HOST_WIDE_INT_1U << (GET_MODE_BITSIZE (mode) - 1
+op1 = gen_int_mode (INTVAL (op1), mode);
+
   tem = expand_shift (RSHIFT_EXPR, mode, op0,
  GET_MODE_BITSIZE (mode) - 1, NULL_RTX, 0);
   tem = expand_and (mode, tem, op1, NULL_RTX);

I thought about adding this code to expand_binop instead but this seems like
something that should be handled by the caller. Also, we don't have
this problem when expanding any other RTL.

However, we do already have somewhat similar behaviour of shifts in expand_binop
  /* For shifts, constant invalid op1 might be expanded from different
 mode than MODE.  As those are invalid, force them to a register
 to avoid further problems during expansion.  */
  else if (CONST_INT_P (op1)
   && shift_optab_p (binoptab)
   && UINTVAL (op1) >= GET_MODE_BITSIZE (GET_MODE_INNER (mode)))
{
  op1 = gen_int_mode (INTVAL (op1), GET_MODE_INNER (mode));
  op1 = force_reg (GET_MODE_INNER (mode), op1);
}

For now I'll stick with the fix in expand_mult_highpart_adjust and see how the
tests go.

Jozef

Re: general_operand not validating "(const_int 65535 [0xffff])"

[Jakub Jelinek]

On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote:
> We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
> When we process the arguments to:
>   __builtin_umul_overflow ((unsigned int) (-1), y, &r);
> at expr.c:8952, they go through a few transformations.
> 
> First we generate the rtx for ((unsigned int) -1) in the HImode context 
> (msp430
> has 16-bit int), which generates (const_int -1). OK.
> Then it gets widened in a SImode context, but since it is unsigned, we zero
> extend and the rtx becomes (const_int 65535). OK.
> When we call expand_mult_highpart_adjust, we are back in HImode, but using
> operands which have been widened in a SImode context. This is when we
> generate our problematic insns using (const_int 65535) with HImode
> operands.

So, what exactly calls expand_mult_highpart_adjust, with what exact
arguments (I see 3 callers).
E.g. the one in expr.c already has:
  if (TREE_CODE (treeop1) == INTEGER_CST)
op1 = convert_modes (mode, word_mode, op1,
 TYPE_UNSIGNED (TREE_TYPE (treeop1)));
and should thus take care of op1.  It doesn't have the same for op0, assumes
that if only one operand is INTEGER_CST, it must be the (canonical) second
one.  So perhaps the bug is that something doesn't canonicalize the order of
arguments?

Jakub

Re: general_operand not validating "(const_int 65535 [0xffff])"

[Jozef Lawrynowicz]

On Wed, 16 Oct 2019 19:02:17 +0200
Jakub Jelinek  wrote:

> On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote:
> > We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
> > When we process the arguments to:
> >   __builtin_umul_overflow ((unsigned int) (-1), y, &r);
> > at expr.c:8952, they go through a few transformations.
> > 
> > First we generate the rtx for ((unsigned int) -1) in the HImode context 
> > (msp430
> > has 16-bit int), which generates (const_int -1). OK.
> > Then it gets widened in a SImode context, but since it is unsigned, we zero
> > extend and the rtx becomes (const_int 65535). OK.
> > When we call expand_mult_highpart_adjust, we are back in HImode, but using
> > operands which have been widened in a SImode context. This is when we
> > generate our problematic insns using (const_int 65535) with HImode
> > operands.  
> 
> So, what exactly calls expand_mult_highpart_adjust, with what exact
> arguments (I see 3 callers).
> E.g. the one in expr.c already has:
>   if (TREE_CODE (treeop1) == INTEGER_CST)
> op1 = convert_modes (mode, word_mode, op1,
>  TYPE_UNSIGNED (TREE_TYPE (treeop1)));
> and should thus take care of op1.  It doesn't have the same for op0, assumes
> that if only one operand is INTEGER_CST, it must be the (canonical) second
> one.  So perhaps the bug is that something doesn't canonicalize the order of
> arguments?
> 
>   Jakub

That convert_modes call is actually what changes op1 from (const_int -1) to
(const_int 65535). In expand_expr_real_2, mode is SImode and word_mode is HImode
for that call.

Info from GDB:
> Breakpoint 2, expand_mult_highpart_adjust ( 
> unsignedp=unsignedp@entry=1) at ../../gcc/expmed.c:3747
> op0 == (reg:HI 23 [ y.0_1 ])
> op1 == (const_int 65535 [0x])
> mode == {m_mode = E_HImode}
> (gdb) bt
> #0  expand_mult_highpart_adjust ( unsignedp=unsignedp@entry=1) at 
> ../../gcc/expmed.c:3747
> #1  0x0085ee18 in expand_expr_real_2 ( 
> tmode=tmode@entry=E_SImode, modifier=modifier@entry=EXPAND_NORMAL) at 
> ../../gcc/expr.c:8963
> #2  0x0098d01d in expand_mul_overflow () at 
> ../../gcc/internal-fn.c:1604
> #3  0x0098fe2d in expand_arith_overflow (code=MULT_EXPR, 
> stmt=) at ../../gcc/internal-fn.c:2362

from expr.c:8946:
if (find_widening_optab_handler (other_optab, mode, innermode)
!= CODE_FOR_nothing
&& innermode == word_mode)
  {
rtx htem, hipart;
op0 = expand_normal (treeop0);
* Below generates (const_int -1) ***
op1 = expand_normal (treeop1);
/* op0 and op1 might be constants, despite the above
   != INTEGER_CST check.  Handle it.  */
if (GET_MODE (op0) == VOIDmode && GET_MODE (op1) == VOIDmode)
  goto widen_mult_const;
if (TREE_CODE (treeop1) == INTEGER_CST)
* Below generates (const_int 65535) **
  op1 = convert_modes (mode, word_mode, op1,
   TYPE_UNSIGNED (TREE_TYPE (treeop1)));
temp = expand_binop (mode, other_optab, op0, op1, target,
 unsignedp, OPTAB_LIB_WIDEN);
hipart = gen_highpart (word_mode, temp);
htem = expand_mult_highpart_adjust (word_mode, hipart,
op0, op1, hipart,
zextend_p);

Maybe the constants should be canonicalized before calling
expand_mult_high_part_adjust? I'm not sure at the moment.

Below patch is an alternative I quickly tried that also fixes the issue, but I
haven't tested it and its not clear if op0 should also be converted.

diff --git a/gcc/expmed.c b/gcc/expmed.c
index f1975fe33fe..25d8edde02e 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -3748,6 +3748,8 @@ expand_mult_highpart_adjust (scalar_int_mode mode, rtx
adj_operand, rtx op0,
   rtx tem;
   enum rtx_code adj_code = unsignedp ? PLUS : MINUS;
 
+  op1 = convert_modes (mode, GET_MODE (XEXP (adj_operand, 0)), op1, unsignedp);
+
   tem = expand_shift (RSHIFT_EXPR, mode, op0,
  GET_MODE_BITSIZE (mode) - 1, NULL_RTX, 0);
   tem = expand_and (mode, tem, op1, NULL_RTX);


Thanks,
Jozef

connecting a QEMU VM to dejagnu...

[Alan Lehotsky]

I’m trying to grapple with connecting dejagnu to a QEMU simulator; not finding 
any obvious examples to work with.

I’ve had a lot of familiarity using CGEN simulators connected to dejagnu, but 
QEMU’s a new breed of cat….

Can anyone point me to a boards/.exp that is based on using QEMU, or 
provide other examples.  

The one example I found via a web search seems to want to do everything in the 
virtual machine - but I have to believe that’s going to be insanely slow…

Re: connecting a QEMU VM to dejagnu...

[Rob Savoye]

On 10/16/19 5:40 PM, Alan Lehotsky via DejaGnu wrote:

> The one example I found via a web search seems to want to do
> everything in the virtual machine - but I have to believe that’s
> going to be insanely slow…

  Well, qemu is a virtual machine... Here's the ones I used for GNU
toolchain cross testing:
https://git.linaro.org/toolchain/abe.git/tree/config/boards. There's a
few on there. If you're building cross compilers, just use ABE and it's
all built in.

- rob -