[patch] Backtrace prints wrong argument value

[patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

Hi Folks,

GDB sometimes acts in an unexpected way while showing backtrace argument
values in certain optimized binaries. I'll go through the example:

The code used to reproduce this follows:

unsigned * __attribute__((noinline))
start_sequence (unsigned * x, unsigned * y)
{
  return (unsigned *)0xdeadbeef;
};

unsigned __attribute__((noinline))
gen_movsd (unsigned * operand0, unsigned * operand1)
{
  return *start_sequence(operand0, operand1);
}

int main(void)
{
  unsigned x, y;

  x = 13;
  y = 14;
  return (int)gen_movsd (&x, &y);
}

Basically we have two functions, gen_movsd and start_sequence. Since the
argument values for those two functions are not really used, GCC
optimizes some of them.

Loading the binary on GDB, we step through the code until we reach the
"start_sequence" function. It shows the following frame info:

#0 - start_sequence (x=<value optimized out>, y=0xfffff9b1b34)

"x" was originally passed on R3, and it's now lost since the same
register was used for the return value (0xdeadbeef) of the
"start_sequence" function. This is OK.

If we call a backtrace on GDB, that's what we have:

#0 - start_sequence (x=<value optimized out>, y=0xfffff9b1b34)
#1 - gen_movsd (operand0=0xdeadbeef, operand1=0xfffff9b1b34)

Notice that on frame #1, "operand0" has a "0xdeadbeef" value, which
happens to be the return value from the "start_sequence" function from
frame #0. This is clearly incorrect.

Stepping a little bit further through the code until we exit from
"start_sequence" and fall back into "gen_movsd", we have the following
as the frame info:

#0 - gen_movsd (operand0=<value optimized out>, operand1=<value
optimized out>)

This last frame info is just correct, since both values aren't available
anymore.

What is causing this incorrect value to be printed on frame levels above
0 is an adjustment to the PC on the "frame_unwind_address_in_block"
function. The purpose of this adjustment to PC is to make it point to
the branch instruction rather than the instruction right after the
branch instruction ( this is achieved with a --pc decrement).

This breaks the code that finds the right DWARF expression in the
location lists for each argument due to an off-by-1 error. Thus, GDB
selects the incorrect DWARF expression and shows the wrong value on
backtrace.

This patch fixes the problem by adjusting the PC to prevent the off-by-1
problem, thus making GDB select the correct DWARF expression.

Another point is that the PC decrement operation on
"frame_unwind_address_in_block", as it is now,  doesn't make sense if
the branch instruction is longer than 1 byte. To make sure that PC
points to the branch instruction we must go back the length of the last
instruction executed. On ppc this length is fixed, but on other
architectures it is not.

Comments and suggestions are welcome.

Best regards,
Luis

[-- Attachment #2: wrong_backtrace_argument.diff --]
[-- Type: text/x-patch, Size: 1292 bytes --]

2007-04-25  Luis Machado  <luisgpm@br.ibm.com>

	* dwarf2loc.c (loclist_read_variable): Corrected the PC value
	before calling the find_location_expression function

Index: gdb/dwarf2loc.c
===================================================================
--- gdb.orig/dwarf2loc.c	2007-04-25 10:29:05.000000000 -0700
+++ gdb/dwarf2loc.c	2007-04-25 11:04:55.000000000 -0700
@@ -528,9 +528,20 @@
   gdb_byte *data;
   size_t size;
 
+/* If the current Frame Level is 0, we pass the unmodified PC, but if the
+   Frame Level is greater than 0, we must adjust the PC by 1 since it was
+   decremented by get_frame_address_in_block() to be more intuitive to the
+   user (to point at the branch instruction rather than the instruction right 
+   after the branch. Due to this adjusting, the Location List has an off-by-1 
+   error when checking the PC. This could cause wrong argument values to be 
+   shown. */
+
   data = find_location_expression (dlbaton, &size,
-				   frame ? get_frame_address_in_block (frame)
-				   : 0);
+          frame ?
+          (frame_relative_level(frame)? (get_frame_address_in_block(frame) + sizeof(CORE_ADDR))
+          : get_frame_address_in_block(frame))
+          : 0);
+
   if (data == NULL)
     {
       val = allocate_value (SYMBOL_TYPE (symbol));

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Wed, Apr 25, 2007 at 03:53:53PM -0300, Luis Machado wrote:
> If we call a backtrace on GDB, that's what we have:
> 
> #0 - start_sequence (x=<value optimized out>, y=0xfffff9b1b34)
> #1 - gen_movsd (operand0=0xdeadbeef, operand1=0xfffff9b1b34)
> 
> Notice that on frame #1, "operand0" has a "0xdeadbeef" value, which
> happens to be the return value from the "start_sequence" function from
> frame #0. This is clearly incorrect.

What is the corresponding code and debug info?

I guess you have debugging information which says that operand0 is
valid on the call instruction and invalid after it.

> What is causing this incorrect value to be printed on frame levels above
> 0 is an adjustment to the PC on the "frame_unwind_address_in_block"
> function. The purpose of this adjustment to PC is to make it point to
> the branch instruction rather than the instruction right after the
> branch instruction ( this is achieved with a --pc decrement).

You've partly misunderstood the purpose of the decrement.  We never
look at the branch instruction; it's to make sure that the PC points
to the same function as the call instruction, in the case of a
function that ends in a call to abort.  Having it point to the middle
of an instruction is perfectly fine.

Consider this code:

func1:
	copy arg1 to r20
	call abort

func2:
	copy arg2 to r3
	call func1
	return

A valid location list for func1 could say that arg1 is valid
in r20 during the call to abort; the -1 puts us on the call, instead
of after it, in the unrelated func2.

I believe this is considered a known weakness of the DWARF
representation, which does not represent state before an instruction
separately from state after it.  The debug info does not tell us
whether the location is valid in the middle of the call.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

> What is the corresponding code and debug info?

This is the complete GDB log:

(gdb) start
Breakpoint 1 at 0x10000600: file pr28136.c, line 18.
Starting program: /home/luis/binaries/pr28136-64
main () at pr.c:18
18        x = 13;
(gdb) s
During symbol reading, incomplete CFI data; unspecified registers (e.g.,
r0) at 0x10000600.
19        y = 14;
(gdb) s
20        return (int)gen_movsd (&x, &y);
(gdb)
gen_movsd (operand0=0xfffff80cb20, operand1=0xfffff80cb24) at pr.c:11
11              return *start_sequence(operand0, operand1);
(gdb)
0x00000000100005b0 in start_sequence (x=<value optimized out>,
y=0xfffff80cb24) at pr.c:6
6       };
(gdb) bt
#0  0x00000000100005b0 in start_sequence (x=<value optimized out>,
y=0xfffff80cb24) at pr.c:6
#1  0x00000000100005d0 in gen_movsd (operand0=0xdeadbeef,
operand1=0xfffff80cb24) at pr.c:11
#2  0x0000000010000618 in main () at pr.c:20
(gdb) s
gen_movsd (operand0=<value optimized out>, operand1=<value optimized
out>) at pr.c:12
12      }
(gdb)

> I guess you have debugging information which says that operand0 is
> valid on the call instruction and invalid after it.

That's the case, "operand0" is valid from low to high where:
low:  0x100005c0
high: 0x100005d0

After that range (including 0x100005d0), "operand0" is invalid, just
like "operand1".

The same happens with "X" from "start_sequence". X is just valid from
0x100005a0 to 0x100005a4.

> You've partly misunderstood the purpose of the decrement.  We never
> look at the branch instruction; it's to make sure that the PC points
> to the same function as the call instruction, in the case of a
> function that ends in a call to abort.  Having it point to the middle
> of an instruction is perfectly fine.
> 
> Consider this code:
> 
> func1:
> 	copy arg1 to r20
> 	call abort
> 
> func2:
> 	copy arg2 to r3
> 	call func1
> 	return
> 

So the whole purpose of the decrement is to maintain the PC inside the
code block of the function that has called a more inner frame function.
It makes sense now. Thanks.

> I believe this is considered a known weakness of the DWARF
> representation, which does not represent state before an instruction
> separately from state after it.  The debug info does not tell us
> whether the location is valid in the middle of the call.

DWARF does seem to lack precision in this case.

In order to keep values consistent throughout all the program's
execution, how would we manage that? It might confuse people debugging
their binaries and facing a different value on backtrace than it is
expected.

It looks like getting the PC back to its original value (after the
function call) would be a good thing since it's desirable that GDB
displays no value at all instead of incorrect ones.

Best regards,
Luis

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

Hi,

Just bringing back the discussion about this little issue on backtrace.

This same behaviour seems to apply to x86 as well, but instead of
showing an incorrect value just on "operand0", it shows them incorrectly
for both "operando0" and "operand1".

That would look like this:

gen_movsd (operand0=0xdeadbeef, operand1=0xdeadbeef)

> > What is the corresponding code and debug info?
> 
> This is the complete GDB log:
> 
> (gdb) start
> Breakpoint 1 at 0x10000600: file pr28136.c, line 18.
> Starting program: /home/luis/binaries/pr28136-64
> main () at pr.c:18
> 18        x = 13;
> (gdb) s
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> r0) at 0x10000600.
> 19        y = 14;
> (gdb) s
> 20        return (int)gen_movsd (&x, &y);
> (gdb)
> gen_movsd (operand0=0xfffff80cb20, operand1=0xfffff80cb24) at pr.c:11
> 11              return *start_sequence(operand0, operand1);
> (gdb)
> 0x00000000100005b0 in start_sequence (x=<value optimized out>,
> y=0xfffff80cb24) at pr.c:6
> 6       };
> (gdb) bt
> #0  0x00000000100005b0 in start_sequence (x=<value optimized out>,
> y=0xfffff80cb24) at pr.c:6
> #1  0x00000000100005d0 in gen_movsd (operand0=0xdeadbeef,
> operand1=0xfffff80cb24) at pr.c:11
> #2  0x0000000010000618 in main () at pr.c:20
> (gdb) s
> gen_movsd (operand0=<value optimized out>, operand1=<value optimized
> out>) at pr.c:12
> 12      }
> (gdb)
> 
> > I guess you have debugging information which says that operand0 is
> > valid on the call instruction and invalid after it.
> 
> That's the case, "operand0" is valid from low to high where:
> low:  0x100005c0
> high: 0x100005d0
> 
> After that range (including 0x100005d0), "operand0" is invalid, just
> like "operand1".
> 
> The same happens with "X" from "start_sequence". X is just valid from
> 0x100005a0 to 0x100005a4.
> 
> > You've partly misunderstood the purpose of the decrement.  We never
> > look at the branch instruction; it's to make sure that the PC points
> > to the same function as the call instruction, in the case of a
> > function that ends in a call to abort.  Having it point to the middle
> > of an instruction is perfectly fine.
> > 
> > Consider this code:
> > 
> > func1:
> > 	copy arg1 to r20
> > 	call abort
> > 
> > func2:
> > 	copy arg2 to r3
> > 	call func1
> > 	return
> > 
> 
> So the whole purpose of the decrement is to maintain the PC inside the
> code block of the function that has called a more inner frame function.
> It makes sense now. Thanks.
> 
> > I believe this is considered a known weakness of the DWARF
> > representation, which does not represent state before an instruction
> > separately from state after it.  The debug info does not tell us
> > whether the location is valid in the middle of the call.
> 
> DWARF does seem to lack precision in this case.
> 
> In order to keep values consistent throughout all the program's
> execution, how would we manage that? It might confuse people debugging
> their binaries and facing a different value on backtrace than it is
> expected.
> 
> It looks like getting the PC back to its original value (after the
> function call) would be a good thing since it's desirable that GDB
> displays no value at all instead of incorrect ones.

Does setting the PC back to its original value during the search for the
correct location expression sound reasonable?

Best Regards,
Luis

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

On Wed, 2007-04-25 at 15:13 -0400, Daniel Jacobowitz wrote:
> A valid location list for func1 could say that arg1 is valid
> in r20 during the call to abort; the -1 puts us on the call, instead
> of after it, in the unrelated func2.
> 
> I believe this is considered a known weakness of the DWARF
> representation, which does not represent state before an instruction
> separately from state after it.  The debug info does not tell us
> whether the location is valid in the middle of the call.

Do you have anything in mind in order to better handle this situation
instead of showing wrong values in backtrace every now and then?

From your comment it wasn't clear if hiding possibly wrong values is
worse than showing them sometimes.

Regards,
Luis

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Wed, May 16, 2007 at 02:34:00AM -0300, Luis Machado wrote:
> On Wed, 2007-04-25 at 15:13 -0400, Daniel Jacobowitz wrote:
> > A valid location list for func1 could say that arg1 is valid
> > in r20 during the call to abort; the -1 puts us on the call, instead
> > of after it, in the unrelated func2.
> > 
> > I believe this is considered a known weakness of the DWARF
> > representation, which does not represent state before an instruction
> > separately from state after it.  The debug info does not tell us
> > whether the location is valid in the middle of the call.
> 
> Do you have anything in mind in order to better handle this situation
> instead of showing wrong values in backtrace every now and then?
> 
> >From your comment it wasn't clear if hiding possibly wrong values is
> worse than showing them sometimes.

There is simply not enough information in the debug info to handle
this correctly.  Let me give you another example:

     move var to r3
     test something
     if true, branch to Lfoo
     call abort, which clobbers r3
Lfoo:
     do something with r3

At every instruction after the move, the debug info should say that
var is in r3.  Right?  No matter which location we pick here, while
backtracing from abort, we'll print the wrong value for var and
there's no point where the debug info will say it is undefined.

If you want us to get this right using DWARF info, I believe your only
choice is to approach the DWARF working group about it.

Now, in GDB we may have other options.  We might be able to get the
list of call clobbered registers based on the ABI.  Compare with s390,
which already does this (dwarf2_frame_set_init_reg).  Does adding
this to PowerPC help your example any?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

> At every instruction after the move, the debug info should say that
> var is in r3.  Right?  No matter which location we pick here, while
> backtracing from abort, we'll print the wrong value for var and
> there's no point where the debug info will say it is undefined.

In such a case, the debug info would still say that the value is valid
and point to the "wrong" place, that's clearly a fault from DWARF's
side.
 
> If you want us to get this right using DWARF info, I believe your only
> choice is to approach the DWARF working group about it.

I believe this would be a better solution, but would require changes to
other toolchain projects and would surely take time. It could be
prohibitive right now.

> Now, in GDB we may have other options.  We might be able to get the
> list of call clobbered registers based on the ABI.  Compare with s390,
> which already does this (dwarf2_frame_set_init_reg).  Does adding
> this to PowerPC help your example any?

I'll check this code. Thanks.

If there is a way to temporarily store those values that we know for
sure that will be wasted during the next inner frame's function
execution, we could recover them during backtrace. That could add some
complexity to the unwinding procedure though.

Regards,
Luis

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Wed, May 16, 2007 at 12:19:41PM -0300, Luis Machado wrote:
> If there is a way to temporarily store those values that we know for
> sure that will be wasted during the next inner frame's function
> execution, we could recover them during backtrace. That could add some
> complexity to the unwinding procedure though.

This is, generally speaking, impossible.  I hadn't thought of the
init_frame_regs hook last time I looked at this; I hope it helps.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

:ADDPATCH PowerPC-64:

Hi,

Bringing back this topic, i've written a patch to address this issue on
ppc's side, providing a function to specify call-clobbered registers
based on the ABI, similar to the S390's.

Looking forward to suggestions/corrections.

Best regards


> There is simply not enough information in the debug info to handle
> this correctly.  Let me give you another example:
> 
>      move var to r3
>      test something
>      if true, branch to Lfoo
>      call abort, which clobbers r3
> Lfoo:
>      do something with r3
> 
> At every instruction after the move, the debug info should say that
> var is in r3.  Right?  No matter which location we pick here, while
> backtracing from abort, we'll print the wrong value for var and
> there's no point where the debug info will say it is undefined.
> 
> If you want us to get this right using DWARF info, I believe your only
> choice is to approach the DWARF working group about it.
> 
> Now, in GDB we may have other options.  We might be able to get the
> list of call clobbered registers based on the ABI.  Compare with s390,
> which already does this (dwarf2_frame_set_init_reg).  Does adding
> this to PowerPC help your example any?
> 
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

[-- Attachment #2: call-clobbered-registers.diff --]
[-- Type: text/x-patch, Size: 3177 bytes --]

2007-09-13  Luis Machado  <luisgpm@br.ibm.com>

    * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
    (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
    default dwarf2_frame_set_init_reg function.

Index: gdb/rs6000-tdep.c
===================================================================
--- gdb.orig/rs6000-tdep.c	2007-09-13 07:26:12.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-09-13 07:41:10.000000000 -0700
@@ -3468,6 +3468,68 @@
   return &rs6000_frame_base;
 }
 
+/* DWARF-2 frame support. Used to handle the detection of
+   clobbered registers during function calls.  */
+
+ static void
+ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
+                            struct dwarf2_frame_state_reg *reg,
+          struct frame_info *next_frame)
+{
+
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  /* PPC32 and PPC64 ABI's are the same regarding volatile and
+     non-volatile registers. We will use the same code for both.  */
+
+  /* Call-saved GP registers.  */
+  if ((regnum >= (tdep->ppc_gp0_regnum + 14)
+    && regnum <= (tdep->ppc_gp0_regnum + 31))
+    || (regnum == (tdep->ppc_gp0_regnum + 1)))
+    reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+  /* Call-clobbered GP registers.  */
+  if ((regnum >= (tdep->ppc_gp0_regnum + 3)
+    && regnum <= (tdep->ppc_gp0_regnum + 12))
+    || (regnum == tdep->ppc_gp0_regnum))
+    reg->how = DWARF2_FRAME_REG_UNDEFINED;
+
+  /* Deal with FP registers, if supported.  */
+  if (tdep->ppc_fp0_regnum >= 0)
+    {
+      /* Call-saved FP registers.  */
+      if ((regnum >= (tdep->ppc_fp0_regnum + 14)
+        && regnum <= (tdep->ppc_fp0_regnum + 31)))
+        reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered FP registers.  */
+      if ((regnum >= (tdep->ppc_fp0_regnum)
+        && regnum <= (tdep->ppc_fp0_regnum + 13)))
+        reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Deal with ALTIVEC registers, if supported.  */
+  if (tdep->ppc_vr0_regnum > 0 && tdep->ppc_vrsave_regnum > 0)
+    {
+      /* Call-saved Altivec registers.  */
+      if ((regnum >= (tdep->ppc_vr0_regnum + 20)
+        && regnum <= (tdep->ppc_vr0_regnum + 31))
+        || regnum == tdep->ppc_vrsave_regnum)
+        reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered Altivec registers.  */
+      if ((regnum >= (tdep->ppc_vr0_regnum)
+        && regnum <= (tdep->ppc_vr0_regnum + 19)))
+        reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  if (regnum == gdbarch_pc_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_RA;
+  else if (regnum == gdbarch_sp_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_CFA;
+}
+
+
 /* Initialize the current architecture based on INFO.  If possible, re-use an
    architecture from ARCHES, which is a list of architectures already created
    during this debugging session.
@@ -3790,6 +3852,10 @@
           tdep->ppc_vr0_regnum = 71;
           tdep->ppc_vrsave_regnum = 104;
         }
+
+      /* Frame handling.  */
+      dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
+
       /* Fall Thru */
     case GDB_OSABI_NETBSD_AOUT:
     case GDB_OSABI_NETBSD_ELF:

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Thu, Sep 13, 2007 at 11:46:05AM -0300, Luis Machado wrote:
> :ADDPATCH PowerPC-64:
> 
> Hi,
> 
> Bringing back this topic, i've written a patch to address this issue on
> ppc's side, providing a function to specify call-clobbered registers
> based on the ABI, similar to the S390's.

:REVIEWMAIL:

I guess this works, then?  That's great.

> 2007-09-13  Luis Machado  <luisgpm@br.ibm.com>
> 
>     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
>     (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
>     default dwarf2_frame_set_init_reg function.

ChangeLog entries should be tab indented - you probably know this and
your mailer ate the tabs?  Indentation all over your patch is wrong,
too.

> +/* DWARF-2 frame support. Used to handle the detection of
> +   clobbered registers during function calls.  */

Two spaces after periods, please.  More occurances below.

> + static void

No leading space there.

> +ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
> +                            struct dwarf2_frame_state_reg *reg,
> +          struct frame_info *next_frame)

Those lines don't line up.  More occurances below.

> +  /* Call-saved GP registers.  */
> +  if ((regnum >= (tdep->ppc_gp0_regnum + 14)
> +    && regnum <= (tdep->ppc_gp0_regnum + 31))
> +    || (regnum == (tdep->ppc_gp0_regnum + 1)))
> +    reg->how = DWARF2_FRAME_REG_SAME_VALUE;

You don't need the parentheses around (tdep->ppc_gp0_regnum + 14), et
cetera; >= and <= are very low precedence.

> @@ -3790,6 +3852,10 @@
>            tdep->ppc_vr0_regnum = 71;
>            tdep->ppc_vrsave_regnum = 104;
>          }
> +
> +      /* Frame handling.  */
> +      dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
> +
>        /* Fall Thru */
>      case GDB_OSABI_NETBSD_AOUT:
>      case GDB_OSABI_NETBSD_ELF:

I don't think this should be GNU/Linux specific, so it should probably
be elsewhere (before gdbarch_init_osabi).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

:ADDPATCH PowerPC-64:

Daniel,

Thanks for reviewing.

Yeah, i definitely had issues with my editor and the tabs ended up being
expanded to spaces. Hopefully this version is correct now. I hope my
mail client doesn't mess the tabs.

> I guess this works, then?  That's great.

Yes, it improves the situation quite a bit, since now only parameters
that are sure to be correct are displayed. If there's a chance of that
parameter being unreliable, then gdb won't display its value (optimized
out).

Best regards,

-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

[-- Attachment #2: call-clobbered-registers.diff --]
[-- Type: text/x-patch, Size: 3347 bytes --]

2007-09-17  Luis Machado  <luisgpm@br.ibm.com>

		* rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
		(rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
		default dwarf2_frame_set_init_reg function.

Index: gdb/rs6000-tdep.c
===================================================================
--- gdb.orig/rs6000-tdep.c	2007-09-17 05:15:37.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-09-17 05:41:23.000000000 -0700
@@ -3468,6 +3468,68 @@
   return &rs6000_frame_base;
 }
 
+/* DWARF-2 frame support.  Used to handle the detection of
+	 clobbered registers during function calls.  */
+
+static void
+ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
+						struct dwarf2_frame_state_reg *reg,
+						struct frame_info *next_frame)
+{
+	struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+	/* PPC32 and PPC64 ABI's are the same regarding volatile and
+		non-volatile registers.  We will use the same code for both.  */
+
+	/* Call-saved GP registers.  */
+	if ((regnum >= tdep->ppc_gp0_regnum + 14
+			&& regnum <= tdep->ppc_gp0_regnum + 31)
+			|| (regnum == tdep->ppc_gp0_regnum + 1))
+		reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+	/* Call-clobbered GP registers.  */
+	if ((regnum >= tdep->ppc_gp0_regnum + 3
+			&& regnum <= tdep->ppc_gp0_regnum + 12)
+			|| (regnum == tdep->ppc_gp0_regnum))
+		reg->how = DWARF2_FRAME_REG_UNDEFINED;
+
+	/* Deal with FP registers, if supported.  */
+	if (tdep->ppc_fp0_regnum >= 0)
+		{
+			/* Call-saved FP registers.  */
+			if ((regnum >= tdep->ppc_fp0_regnum + 14
+					&& regnum <= tdep->ppc_fp0_regnum + 31))
+				reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+			/* Call-clobbered FP registers.  */
+			if ((regnum >= tdep->ppc_fp0_regnum
+					&& regnum <= tdep->ppc_fp0_regnum + 13))
+				reg->how = DWARF2_FRAME_REG_UNDEFINED;
+		}
+
+	/* Deal with ALTIVEC registers, if supported.  */
+	if (tdep->ppc_vr0_regnum > 0 && tdep->ppc_vrsave_regnum > 0)
+		{
+			/* Call-saved Altivec registers.  */
+			if ((regnum >= tdep->ppc_vr0_regnum + 20
+					&& regnum <= tdep->ppc_vr0_regnum + 31)
+					|| regnum == tdep->ppc_vrsave_regnum)
+				reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+			/* Call-clobbered Altivec registers.  */
+			if ((regnum >= tdep->ppc_vr0_regnum
+					&& regnum <= tdep->ppc_vr0_regnum + 19))
+				reg->how = DWARF2_FRAME_REG_UNDEFINED;
+		}
+
+	/* Handle PC register and Stack Pointer correctly.  */
+	if (regnum == gdbarch_pc_regnum (current_gdbarch))
+		reg->how = DWARF2_FRAME_REG_RA;
+	else if (regnum == gdbarch_sp_regnum (current_gdbarch))
+		reg->how = DWARF2_FRAME_REG_CFA;
+}
+
+
 /* Initialize the current architecture based on INFO.  If possible, re-use an
    architecture from ARCHES, which is a list of architectures already created
    during this debugging session.
@@ -3774,6 +3836,9 @@
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
   dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
 
+	/* Frame handling.  */
+	dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
+
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
@@ -3790,6 +3855,7 @@
           tdep->ppc_vr0_regnum = 71;
           tdep->ppc_vrsave_regnum = 104;
         }
+
       /* Fall Thru */
     case GDB_OSABI_NETBSD_AOUT:
     case GDB_OSABI_NETBSD_ELF:

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 10:04:38AM -0300, Luis Machado wrote:
> :ADDPATCH PowerPC-64:
> 
> Daniel,
> 
> Thanks for reviewing.
> 
> Yeah, i definitely had issues with my editor and the tabs ended up being
> expanded to spaces. Hopefully this version is correct now. I hope my
> mail client doesn't mess the tabs.

Ouch, this one's even worse.  All your tabs were doubled.  I've never
seen that happen before.
> @@ -3774,6 +3836,9 @@
>    frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
>    dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
>  
> +	/* Frame handling.  */
> +	dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
> +
>    /* Hook in ABI-specific overrides, if they have been registered.  */
>    gdbarch_init_osabi (info, gdbarch);
>  

Not sure why there's a tab in that - mailer trouble again?  Above and
below are indented with only two spaces.

> @@ -3790,6 +3855,7 @@
>            tdep->ppc_vr0_regnum = 71;
>            tdep->ppc_vrsave_regnum = 104;
>          }
> +
>        /* Fall Thru */
>      case GDB_OSABI_NETBSD_AOUT:
>      case GDB_OSABI_NETBSD_ELF:

Stray blank line here.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

From the mail body it's doubled, it seems, due to my mailer. Did you try
to just save the attached file? That works correct for me, and it's the
only way i can trust it will work right.

If that doesn't work, let me know and i'll submit again in a different
way.

Regards

On Mon, 2007-09-17 at 09:15 -0400, Daniel Jacobowitz wrote:
> On Mon, Sep 17, 2007 at 10:04:38AM -0300, Luis Machado wrote:
> > 
> > Daniel,
> > 
> > Thanks for reviewing.
> > 
> > Yeah, i definitely had issues with my editor and the tabs ended up being
> > expanded to spaces. Hopefully this version is correct now. I hope my
> > mail client doesn't mess the tabs.
> 
> Ouch, this one's even worse.  All your tabs were doubled.  I've never
> seen that happen before.
> > @@ -3774,6 +3836,9 @@
> >    frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
> >    dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
> >  
> > +	/* Frame handling.  */
> > +	dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
> > +
> >    /* Hook in ABI-specific overrides, if they have been registered.  */
> >    gdbarch_init_osabi (info, gdbarch);
> >  
> 
> Not sure why there's a tab in that - mailer trouble again?  Above and
> below are indented with only two spaces.
> 
> > @@ -3790,6 +3855,7 @@
> >            tdep->ppc_vr0_regnum = 71;
> >            tdep->ppc_vrsave_regnum = 104;
> >          }
> > +
> >        /* Fall Thru */
> >      case GDB_OSABI_NETBSD_AOUT:
> >      case GDB_OSABI_NETBSD_ELF:
> 
> Stray blank line here.
> 
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 10:29:39AM -0300, Luis Machado wrote:
> >From the mail body it's doubled, it seems, due to my mailer. Did you try
> to just save the attached file? That works correct for me, and it's the
> only way i can trust it will work right.
> 
> If that doesn't work, let me know and i'll submit again in a different
> way.

Nope, it's still corrupted.  I don't know why...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

That's gotta be my mail client. I'll submit it shortly.

Regards,

On Mon, 2007-09-17 at 09:37 -0400, Daniel Jacobowitz wrote:
> On Mon, Sep 17, 2007 at 10:29:39AM -0300, Luis Machado wrote:
> > >From the mail body it's doubled, it seems, due to my mailer. Did you try
> > to just save the attached file? That works correct for me, and it's the
> > only way i can trust it will work right.
> > 
> > If that doesn't work, let me know and i'll submit again in a different
> > way.
> 
> Nope, it's still corrupted.  I don't know why...
> 
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

Hopefully the last chapter in the "broken by mailer" series. :-)

Tabs had to expand to spaces in order to appear correctly in the body of
the message.

Regards,
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

[-- Attachment #2: call-clobbered-registers.diff --]
[-- Type: text/x-patch, Size: 3480 bytes --]

2007-09-17  Luis Machado  <luisgpm@br.ibm.com>

    * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
      (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
      default dwarf2_frame_set_init_reg function.

Index: gdb/rs6000-tdep.c
===================================================================
--- gdb.orig/rs6000-tdep.c	2007-09-17 06:41:23.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-09-17 06:55:57.000000000 -0700
@@ -3468,6 +3468,68 @@
   return &rs6000_frame_base;
 }
 
+/* DWARF-2 frame support.  Used to handle the detection of
+   clobbered registers during function calls.  */
+
+static void
+ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
+            struct dwarf2_frame_state_reg *reg,
+            struct frame_info *next_frame)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  /* PPC32 and PPC64 ABI's are the same regarding volatile and
+    non-volatile registers.  We will use the same code for both.  */
+
+  /* Call-saved GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 14
+      && regnum <= tdep->ppc_gp0_regnum + 31)
+      || (regnum == tdep->ppc_gp0_regnum + 1))
+    reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+  /* Call-clobbered GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 3
+      && regnum <= tdep->ppc_gp0_regnum + 12)
+      || (regnum == tdep->ppc_gp0_regnum))
+    reg->how = DWARF2_FRAME_REG_UNDEFINED;
+
+  /* Deal with FP registers, if supported.  */
+  if (tdep->ppc_fp0_regnum >= 0)
+    {
+      /* Call-saved FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum + 14
+          && regnum <= tdep->ppc_fp0_regnum + 31))
+        reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum
+          && regnum <= tdep->ppc_fp0_regnum + 13))
+        reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Deal with ALTIVEC registers, if supported.  */
+  if (tdep->ppc_vr0_regnum > 0 && tdep->ppc_vrsave_regnum > 0)
+    {
+      /* Call-saved Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum + 20
+          && regnum <= tdep->ppc_vr0_regnum + 31)
+          || regnum == tdep->ppc_vrsave_regnum)
+        reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum
+          && regnum <= tdep->ppc_vr0_regnum + 19))
+        reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Handle PC register and Stack Pointer correctly.  */
+  if (regnum == gdbarch_pc_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_RA;
+  else if (regnum == gdbarch_sp_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_CFA;
+}
+
+
 /* Initialize the current architecture based on INFO.  If possible, re-use an
    architecture from ARCHES, which is a list of architectures already created
    during this debugging session.
@@ -3774,6 +3836,9 @@
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
   dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
 
+  /* Frame handling.  */
+  dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
+
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
@@ -3790,6 +3855,7 @@
           tdep->ppc_vr0_regnum = 71;
           tdep->ppc_vrsave_regnum = 104;
         }
+
       /* Fall Thru */
     case GDB_OSABI_NETBSD_AOUT:
     case GDB_OSABI_NETBSD_ELF:

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 11:00:23AM -0300, Luis Machado wrote:
> Hopefully the last chapter in the "broken by mailer" series. :-)
> 
> Tabs had to expand to spaces in order to appear correctly in the body of
> the message.

No luck.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

One more try.

On Mon, 2007-09-17 at 10:04 -0400, Daniel Jacobowitz wrote:
> On Mon, Sep 17, 2007 at 11:00:23AM -0300, Luis Machado wrote:
> > Hopefully the last chapter in the "broken by mailer" series. :-)
> > 
> > Tabs had to expand to spaces in order to appear correctly in the body of
> > the message.
> 
> No luck.
> 
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

[-- Attachment #2: call-clobbered-registers.diff --]
[-- Type: text/x-patch, Size: 3200 bytes --]

2007-09-17  Luis Machado  <luisgpm@br.ibm.com>

    * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
      (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
      default dwarf2_frame_set_init_reg function.

Index: gdb/rs6000-tdep.c
===================================================================
--- gdb.orig/rs6000-tdep.c	2007-09-17 06:41:23.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-09-17 07:42:59.000000000 -0700
@@ -3468,6 +3468,68 @@
   return &rs6000_frame_base;
 }
 
+/* DWARF-2 frame support.  Used to handle the detection of
+  clobbered registers during function calls.  */
+
+static void
+ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
+	    struct dwarf2_frame_state_reg *reg,
+	    struct frame_info *next_frame)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  /* PPC32 and PPC64 ABI's are the same regarding volatile and
+     non-volatile registers.  We will use the same code for both.  */
+
+  /* Call-saved GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 14
+      && regnum <= tdep->ppc_gp0_regnum + 31)
+      || (regnum == tdep->ppc_gp0_regnum + 1))
+    reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+  /* Call-clobbered GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 3
+      && regnum <= tdep->ppc_gp0_regnum + 12)
+      || (regnum == tdep->ppc_gp0_regnum))
+    reg->how = DWARF2_FRAME_REG_UNDEFINED;
+
+  /* Deal with FP registers, if supported.  */
+  if (tdep->ppc_fp0_regnum >= 0)
+    {
+      /* Call-saved FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum + 14
+	  && regnum <= tdep->ppc_fp0_regnum + 31))
+	reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum
+	  && regnum <= tdep->ppc_fp0_regnum + 13))
+	reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Deal with ALTIVEC registers, if supported.  */
+  if (tdep->ppc_vr0_regnum > 0 && tdep->ppc_vrsave_regnum > 0)
+    {
+      /* Call-saved Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum + 20
+	  && regnum <= tdep->ppc_vr0_regnum + 31)
+	  || regnum == tdep->ppc_vrsave_regnum)
+	reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum
+	  && regnum <= tdep->ppc_vr0_regnum + 19))
+	reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Handle PC register and Stack Pointer correctly.  */
+  if (regnum == gdbarch_pc_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_RA;
+  else if (regnum == gdbarch_sp_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_CFA;
+}
+
+
 /* Initialize the current architecture based on INFO.  If possible, re-use an
    architecture from ARCHES, which is a list of architectures already created
    during this debugging session.
@@ -3774,6 +3836,9 @@
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
   dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
 
+  /* Frame handling.  */
+  dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
+
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

Daniel,

This version appears to fix the tabs, spaces and identation.

-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

[-- Attachment #2: call-clobbered-registers.diff --]
[-- Type: text/x-patch, Size: 3204 bytes --]

2007-09-17  Luis Machado  <luisgpm@br.ibm.com>

    * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
      (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
      default dwarf2_frame_set_init_reg function.

Index: gdb/rs6000-tdep.c
===================================================================
--- gdb.orig/rs6000-tdep.c	2007-09-17 06:41:23.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-09-17 10:05:27.000000000 -0700
@@ -3468,6 +3468,68 @@
   return &rs6000_frame_base;
 }
 
+/* DWARF-2 frame support.  Used to handle the detection of
+  clobbered registers during function calls.  */
+
+static void
+ppc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
+			    struct dwarf2_frame_state_reg *reg,
+			    struct frame_info *next_frame)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  /* PPC32 and PPC64 ABI's are the same regarding volatile and
+     non-volatile registers.  We will use the same code for both.  */
+
+  /* Call-saved GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 14
+      && regnum <= tdep->ppc_gp0_regnum + 31)
+      || (regnum == tdep->ppc_gp0_regnum + 1))
+    reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+  /* Call-clobbered GP registers.  */
+  if ((regnum >= tdep->ppc_gp0_regnum + 3
+      && regnum <= tdep->ppc_gp0_regnum + 12)
+      || (regnum == tdep->ppc_gp0_regnum))
+    reg->how = DWARF2_FRAME_REG_UNDEFINED;
+
+  /* Deal with FP registers, if supported.  */
+  if (tdep->ppc_fp0_regnum >= 0)
+    {
+      /* Call-saved FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum + 14
+	  && regnum <= tdep->ppc_fp0_regnum + 31))
+	reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered FP registers.  */
+      if ((regnum >= tdep->ppc_fp0_regnum
+	  && regnum <= tdep->ppc_fp0_regnum + 13))
+	reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Deal with ALTIVEC registers, if supported.  */
+  if (tdep->ppc_vr0_regnum > 0 && tdep->ppc_vrsave_regnum > 0)
+    {
+      /* Call-saved Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum + 20
+	  && regnum <= tdep->ppc_vr0_regnum + 31)
+	  || regnum == tdep->ppc_vrsave_regnum)
+	reg->how = DWARF2_FRAME_REG_SAME_VALUE;
+
+      /* Call-clobbered Altivec registers.  */
+      if ((regnum >= tdep->ppc_vr0_regnum
+	  && regnum <= tdep->ppc_vr0_regnum + 19))
+	reg->how = DWARF2_FRAME_REG_UNDEFINED;
+    }
+
+  /* Handle PC register and Stack Pointer correctly.  */
+  if (regnum == gdbarch_pc_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_RA;
+  else if (regnum == gdbarch_sp_regnum (current_gdbarch))
+    reg->how = DWARF2_FRAME_REG_CFA;
+}
+
+
 /* Initialize the current architecture based on INFO.  If possible, re-use an
    architecture from ARCHES, which is a list of architectures already created
    during this debugging session.
@@ -3774,6 +3836,9 @@
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
   dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
 
+  /* Frame handling.  */
+  dwarf2_frame_set_init_reg (gdbarch, ppc_dwarf2_frame_init_reg);
+
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 02:15:06PM -0300, Luis Machado wrote:
> Daniel,
> 
> This version appears to fix the tabs, spaces and identation.

Thanks.  Hopefully, we won't have to go through this again :-)

> 2007-09-17  Luis Machado  <luisgpm@br.ibm.com>
> 
>     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
>       (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
>       default dwarf2_frame_set_init_reg function.

OK.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

> Thanks.  Hopefully, we won't have to go through this again :-)

Thanks for reviewing and also for the patience. :-)

:REVIEWMAIL:

Do you think this could make its way to 6.7?

-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 02:33:46PM -0300, Luis Machado wrote:
> > Thanks.  Hopefully, we won't have to go through this again :-)
> 
> Thanks for reviewing and also for the patience. :-)
> 
> :REVIEWMAIL:
> 
> Do you think this could make its way to 6.7?

I don't see any reason why it shouldn't.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

On Mon, 2007-09-17 at 13:48 -0400, Daniel Jacobowitz wrote:
> On Mon, Sep 17, 2007 at 02:33:46PM -0300, Luis Machado wrote:
> > > Thanks.  Hopefully, we won't have to go through this again :-)
> > 
> > Thanks for reviewing and also for the patience. :-)
> > 
> > :REVIEWMAIL:
> > 
> > Do you think this could make its way to 6.7?
> 
> I don't see any reason why it shouldn't.
> 

Ulrich, do you think this could go in as well?

Regards,
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [patch] Backtrace prints wrong argument value

[Luis Machado]

On Mon, 2007-09-17 at 13:18 -0400, Daniel Jacobowitz wrote:
> On Mon, Sep 17, 2007 at 02:15:06PM -0300, Luis Machado wrote:
> > Daniel,
> > 
> > This version appears to fix the tabs, spaces and identation.
> 
> Thanks.  Hopefully, we won't have to go through this again :-)
> 
> > 2007-09-17  Luis Machado  <luisgpm@br.ibm.com>
> > 
> >     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
> >       (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
> >       default dwarf2_frame_set_init_reg function.
> 
> OK.
> 

Thanks. I've commited this now.

Regards,
-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [patch] Backtrace prints wrong argument value

[Joel Brobecker]

> > > 2007-09-17  Luis Machado  <luisgpm@br.ibm.com>
> > > 
> > >     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
> > >       (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
> > >       default dwarf2_frame_set_init_reg function.
> > 
> > OK.
> > 
> 
> Thanks. I've commited this now.

Luis asked me whether he could commit to the branch.  I looked at the
patch, and it seems pretty safe to me. Does anyone have reservations
about this going to the branch? Daniel?

Thanks,
-- 
Joel

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Sun, Oct 21, 2007 at 04:28:37PM -0700, Joel Brobecker wrote:
> > > > 2007-09-17  Luis Machado  <luisgpm@br.ibm.com>
> > > > 
> > > >     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
> > > >       (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
> > > >       default dwarf2_frame_set_init_reg function.
> > > 
> > > OK.
> > > 
> > 
> > Thanks. I've commited this now.
> 
> Luis asked me whether he could commit to the branch.  I looked at the
> patch, and it seems pretty safe to me. Does anyone have reservations
> about this going to the branch? Daniel?

Sounds fine to me.

There are now a pile (three, I believe) of PRs about Solaris build
failures.  Is there someone familiar with Solaris who could take a
look at them?  I think we have one at work that I could borrow for
this, but it'll take me a while.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Joel Brobecker]

> > > > > 2007-09-17  Luis Machado  <luisgpm@br.ibm.com>
> > > > > 
> > > > >     * rs6000-tdep.c (ppc_dwarf2_frame_init_reg): New function.
> > > > >       (rs6000_gdbarch_init): Install ppc_dwarf2_frame_init_reg as 
> > > > >       default dwarf2_frame_set_init_reg function.
> > > > 
> > > > OK.
> > > > 
> > > 
> > > Thanks. I've commited this now.
> > 
> > Luis asked me whether he could commit to the branch.  I looked at the
> > patch, and it seems pretty safe to me. Does anyone have reservations
> > about this going to the branch? Daniel?
> 
> Sounds fine to me.

Thanks for the feedback. Luis, I think this is enough approval for
it to go to the branch.

> There are now a pile (three, I believe) of PRs about Solaris build
> failures.  Is there someone familiar with Solaris who could take a
> look at them?  I think we have one at work that I could borrow for
> this, but it'll take me a while.

Could you point me to them? I will be tied up for the next two weeks
(I'm actually traveling oct-28/nov-02), but I can have a look when
I return.

I propose that we re-use the gdb-6.7 release wiki page to document
the issues we need to fix before gdb-6.7.1. I can add these Solaris
one.

-- 
Joel

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Sun, Oct 21, 2007 at 08:31:14PM -0700, Joel Brobecker wrote:
> > There are now a pile (three, I believe) of PRs about Solaris build
> > failures.  Is there someone familiar with Solaris who could take a
> > look at them?  I think we have one at work that I could borrow for
> > this, but it'll take me a while.
> 
> Could you point me to them? I will be tied up for the next two weeks
> (I'm actually traveling oct-28/nov-02), but I can have a look when
> I return.

With Pedro's help, two are now fixed.  Only build/2339 remains.  But
that's with SunPro and I don't think it's a blocker - so we are
probably good to go now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Joel Brobecker]

> With Pedro's help, two are now fixed.  Only build/2339 remains.  But
> that's with SunPro and I don't think it's a blocker - so we are
> probably good to go now.

OK, I'd like to also include the piece of NEWS for hppa64-hpux
(which I'm about to submit). Shall we target Friday or early
next week?

-- 
Joel

Re: [patch] Backtrace prints wrong argument value

[Daniel Jacobowitz]

On Wed, Oct 24, 2007 at 01:58:33PM -0700, Joel Brobecker wrote:
> > With Pedro's help, two are now fixed.  Only build/2339 remains.  But
> > that's with SunPro and I don't think it's a blocker - so we are
> > probably good to go now.
> 
> OK, I'd like to also include the piece of NEWS for hppa64-hpux
> (which I'm about to submit). Shall we target Friday or early
> next week?

That sounds like a good idea.

I should really try to get a patch for hppa-linux checked in.  It
doesn't build with current kernel headers, and may not have for
quite a while.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Backtrace prints wrong argument value

[Pedro Alves]

Daniel Jacobowitz wrote:

> With Pedro's help, two are now fixed.  Only build/2339 remains.  But
> that's with SunPro and I don't think it's a blocker - so we are
> probably good to go now.
>

Irk.  I've seen that happen too a few months ago, but totally forgot
about it.  That happens due to the your's trully and Nick's
new STRING_COMMA_LEN in bfd.

bfd-in.h:#define STRING_COMMA_LEN(STR) (STR), ((STR) ? sizeof (STR) - 1 : 0)

SunPro doesn't like the '?' operator for constant initilizers.

elf.c", line 856: non-constant initializer: op "?"

The fix is easy - inline the STRING_COMMA_LEN(NULL) cases.
Wait, a quick 'grep STRING_COMMA_LEN * -rn | grep NULL' shows
there aren't any?

This should fix it.  I'll see if I can give it a spin with SunPro this week, but
no promises.

-#define STRING_COMMA_LEN(STR) (STR), ((STR) ? sizeof (STR) - 1 : 0)
+#define STRING_COMMA_LEN(STR) (STR), (sizeof (STR) - 1)

Cheers,
Pedro Alves

Re: [patch] Backtrace prints wrong argument value

[Pedro Alves]

Pedro Alves wrote:

> The fix is easy - inline the STRING_COMMA_LEN(NULL) cases.
> Wait, a quick 'grep STRING_COMMA_LEN * -rn | grep NULL' shows
> there aren't any?
>

:) Forgot to grep in ld.

There are only 6 of those in ld/pe-dll.c in a not-so-recent binutils checkout I
have here, so it should be painless.

Cheers,
Pedro Alves