[PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

This patch simply adds an external entry point (dwarf2_execute_stack_op), 
that doesn't require the CFA context. It also adds code so that when the 
context passed to execute_stack_op is NULL, we use read_register_gen to 
get registers.

Along the way, I made an obvious fix to DW_OP_deref_size that i'll commit 
separately, but included in the changelog/patch because i didn't want to 
hand edit it out.


I also added my name to the top of the file, since in reality, it's based 
on code I sent Jiri.

--Dan
2002-03-25  Daniel Berlin  <dan@dberlin.org>

	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
	entry point to execute_stack_op that doesn't require context.
	(execute_stack_op): If context is NULL, don't use get_reg, use
	read_register_gen.
        Also fix bug in DW_OP_deref_size.

	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
Index: dwarf2cfi.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2cfi.c,v
retrieving revision 1.1
diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.c
*** dwarf2cfi.c	2001/12/07 12:10:15	1.1
--- dwarf2cfi.c	2002/03/25 23:50:16
***************
*** 1,7 ****
  /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
!    Copyright 2001
     Free Software Foundation, Inc.
     Contributed by Jiri Smid, SuSE Labs.
  
     This file is part of GDB.
  
--- 1,8 ----
  /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
!    Copyright 2001, 2002
     Free Software Foundation, Inc.
     Contributed by Jiri Smid, SuSE Labs.
+    Based on code written by Daniel Berlin (dan@dberlin.org)
  
     This file is part of GDB.
  
*************** get_reg (char *reg, struct context *cont
*** 840,845 ****
--- 841,854 ----
      }
  }
  
+ /* External entry point for executing dwarf2 stack operations. */
+ CORE_ADDR
+ dwarf2_execute_stack_op (struct objfile *objfile, char *op_ptr,
+ 			 char *op_end, CORE_ADDR initial)
+ {
+   return execute_stack_op (objfile, op_ptr, op_end, NULL, initial);
+ }
+ 
  /* Decode a DW_OP stack program.  Return the top of stack.  Push INITIAL
     onto the stack to start.  */
  static CORE_ADDR
*************** execute_stack_op (struct objfile *objfil
*** 963,973 ****
--- 972,989 ----
  	case DW_OP_reg29:
  	case DW_OP_reg30:
  	case DW_OP_reg31:
+ 	  if (context)
  	    get_reg ((char *) &result, context, op - DW_OP_reg0);
+ 	  else
+ 	    read_register_gen (op - DW_OP_reg0, (char *)&result);
+ 	  
  	  break;
  	case DW_OP_regx:
  	  reg = read_uleb128 (objfile->obfd, &op_ptr);
+ 	  if (context)
  	    get_reg ((char *) &result, context, reg);
+ 	  else
+ 	    read_register_gen (reg, (char *)&result);
  	  break;
  
  	case DW_OP_breg0:
*************** execute_stack_op (struct objfile *objfil
*** 1003,1015 ****
--- 1019,1038 ----
  	case DW_OP_breg30:
  	case DW_OP_breg31:
  	  offset = read_sleb128 (objfile->obfd, &op_ptr);
+ 	  if (context)
  	    get_reg ((char *) &result, context, op - DW_OP_breg0);
+ 	  else
+ 	    read_register_gen (op - DW_OP_breg0, (char *)&result);
+ 	  
  	  result += offset;
  	  break;
  	case DW_OP_bregx:
  	  reg = read_uleb128 (objfile->obfd, &op_ptr);
  	  offset = read_sleb128 (objfile->obfd, &op_ptr);
+ 	  if (context)
  	    get_reg ((char *) &result, context, reg);
+ 	  else
+ 	    read_register_gen (reg, (char *)&result);
  	  result += offset;
  	  break;
  
*************** execute_stack_op (struct objfile *objfil
*** 1067,1080 ****
  	    {
  	    case DW_OP_deref:
  	      {
! 		char *ptr = (char *) result;
  		result = read_pointer (objfile->obfd, &ptr);
  	      }
  	      break;
  
  	    case DW_OP_deref_size:
  	      {
! 		char *ptr = (char *) result;
  		switch (*op_ptr++)
  		  {
  		  case 1:
--- 1090,1103 ----
  	    {
  	    case DW_OP_deref:
  	      {
! 		char *ptr = (char *) &result;
  		result = read_pointer (objfile->obfd, &ptr);
  	      }
  	      break;
  
  	    case DW_OP_deref_size:
  	      {
! 		char *ptr = (char *) &result;
  		switch (*op_ptr++)
  		  {
  		  case 1:
Index: dwarf2cfi.h
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2cfi.h,v
retrieving revision 1.1
diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.h
*** dwarf2cfi.h	2001/12/07 12:10:15	1.1
--- dwarf2cfi.h	2002/03/25 23:50:16
*************** void cfi_get_saved_register (char *raw_b
*** 63,66 ****
--- 63,72 ----
  void cfi_virtual_frame_pointer (CORE_ADDR pc, int *frame_regnum,
  				LONGEST * frame_offset);
  
+ /*  Execute a set of DWARF2 stack operations, starting with INITIAL
+     as the address on the stack. */
+ CORE_ADDR dwarf2_execute_stack_op (struct objfile *objfile, 
+ 				   char *op_ptr, char *op_end,
+ 				   CORE_ADDR initial);
+ 
  #endif
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.2349
diff -c -3 -p -w -B -b -r1.2349 ChangeLog
*** ChangeLog	2002/03/25 19:47:39	1.2349
--- ChangeLog	2002/03/25 23:50:17
***************
*** 1,3 ****
--- 1,12 ----
+ 2002-03-25  Daniel Berlin  <dan@dberlin.org>
+ 
+ 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
+ 	entry point to execute_stack_op that doesn't require context.
+ 	(execute_stack_op): If context is NULL, don't use get_reg, use
+ 	read_register_gen.
+ 
+ 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
+ 
  2002-03-25  Jeff Law (law@redhat.com)
  
  	* linux-proc.c (read_mapping): Scan up to end of line for filename.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> that doesn't require the CFA context. It also adds code so that when the 
> context passed to execute_stack_op is NULL, we use read_register_gen to 
> get registers.

Hmm, where are you going here?

Andrew



> I also added my name to the top of the file, since in reality, it's based 
> on code I sent Jiri.

I'd let Jiri make that decision.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Mon, 25 Mar 2002, Andrew Cagney wrote:

> > This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> > that doesn't require the CFA context. It also adds code so that when the 
> > context passed to execute_stack_op is NULL, we use read_register_gen to 
> > get registers.
> 
> Hmm, where are you going here?

Um, rather than have multiple dwarf2 stack op executors, have one.
In order to do this, it needs to not require CFA context to be able to 
read registers.  

> 
> Andrew
> 
> 
> 
> > I also added my name to the top of the file, since in reality, it's based 
> > on code I sent Jiri.
> 
> I'd let Jiri make that decision.
No.
This is not his decision to make.
A lot of it is my code, unchanged (you can check the x86-64.org 
repository, for the huge change that replaced his code with mine)
He never gave me any credit when he contributed it, for some reason, 
probably because I never asked for it.
I've still got the email I sent him when he asked for the code, and i'm 
sure he'd be happy to confirm he used it.

From a legal standpoint, while the copyright is transfered to the FSF, the 
non-exclusive license they grant back to the contributors code should go 
to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
copyright assignment with the FSF.
Thus, in order to ensure this is possible (not that i plan on using the 
license for anything at the moment), i'm making sure it's clear that the 
code contributed was not soley Jiri's.  
So, that way, in the future, if I ever cared to license the code to 
someone else, or do something with it, I can without someone asserting 
it's only the FSF and Jiri's.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

> > 
> > 
> > 
> > > I also added my name to the top of the file, since in reality, it's based 
> > > on code I sent Jiri.
> > 
> > I'd let Jiri make that decision.
> No.
> This is not his decision to make.
> A lot of it is my code, unchanged (you can check the x86-64.org 
> repository, for the huge change that replaced his code with mine)
> He never gave me any credit when he contributed it, for some reason, 
> probably because I never asked for it.
> I've still got the email I sent him when he asked for the code, and i'm 
> sure he'd be happy to confirm he used it.
> 
> >From a legal standpoint, while the copyright is transfered to the FSF, the 
> non-exclusive license they grant back to the contributors code should go 
> to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
> copyright assignment with the FSF.
> Thus, in order to ensure this is possible (not that i plan on using the 
> license for anything at the moment), i'm making sure it's clear that the 
> code contributed was not soley Jiri's.  
> So, that way, in the future, if I ever cared to license the code to 
> someone else, or do something with it, I can without someone asserting 
> it's only the FSF and Jiri's.

Please be aware, by the way, that if you don't accept the change to the 
top of the file, i'll be forced to go bug RMS/the FSF about it, as I'm 
sure they'd want the code correctly identified as well.

I'm not asking that I be given credit for something I didn't do.  Nor am I 
attempting to diminish in any way the size,quantity, or quality, of 
Jiri's contribution.  I am simply requesting that it be properly 
identified as a derivation of code I wrote.

It's imperative that the lineage of code be correctly identified (in fact, 
if GDB had a legal team, it's the first thing they'd do). In most cases, 
you can determine it from the cvs annotate/the changelogs. However, for 
new contributions, there is no history.  Since I never sent the code 
in question to gdb-patches, it also has no record there.

I only care because I've been getting an increasing number of requests 
from companies wanting to buy the source code to the C++ debugger I wrote 
to replace GDB ( Of course, it uses a variant of the code in question to 
read/execute frame ops).  I blanket refuse such requests in the hopes that 
they'll take the money and pay for GDB work instead, but it's something 
i'd consider if times ever  got really tough.  If there is one thing 
having three rabbits (rabbits  can't learn through negative reinforcement. 
i.e. reprimanding them after they have done something wrong does no good) 
as pets has taught me, it's that it's much easier to make sure a situation 
never happens, than it is to try to do something about it when it 
occurs.

It's not just me, either.  If Jiri/SuSE wanted to license the code to 
someone, he/they  might accidently sign something saying he was the sole 
author, which could make him/them liable, etc.

In short, i'm simply trying to eliminate something that could come back to 
bite me, or others, in the ass, later.

If you really want proof it's my code, I can happily provide this as well.

Since I know you get bogged down in mail, i'll give you till the end of 
the month before I go bug RMS and the FSF about this.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> On Mon, 25 Mar 2002, Andrew Cagney wrote:
> 
> 
>> > This patch simply adds an external entry point (dwarf2_execute_stack_op), 
>> > that doesn't require the CFA context. It also adds code so that when the 
>> > context passed to execute_stack_op is NULL, we use read_register_gen to 
>> > get registers.
> 
>> 
>> Hmm, where are you going here?
> 
> 
> Um, rather than have multiple dwarf2 stack op executors, have one.
> In order to do this, it needs to not require CFA context to be able to 
> read registers.  

Shouldn't the dwarf2 location expression evaluator be separated out 
(dwarf2loc?) and be parameterized with both the frame it is to operate 
within and the expression it is to evaluate.  If the expression 
evaluator needs the value of a register from the frame it just calls 
whatever the frame-get-reg-value(frame) function is.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

[I'm sure Richard Stallman doesn't want to be dragged into such an 
exchange, however]

Given there is currently a dispute over the origins of the file 
dwarf2cfi.c, I'm removing it from GDB.

Once that dispute has been resolved, the file can, again be accepted.

I should note that resolving this will likely take time - Jiri is 
currently uncontactable, so I'm going to to have to try to follow this 
up with his peers.

sigh,
Andrew

> I also added my name to the top of the file, since in reality, it's based 
>> > > on code I sent Jiri.
> 
>> > 
>> > I'd let Jiri make that decision.
> 
>> No.
>> This is not his decision to make.
>> A lot of it is my code, unchanged (you can check the x86-64.org 
>> repository, for the huge change that replaced his code with mine)
>> He never gave me any credit when he contributed it, for some reason, 
>> probably because I never asked for it.
>> I've still got the email I sent him when he asked for the code, and i'm 
>> sure he'd be happy to confirm he used it.
>> 
>> >From a legal standpoint, while the copyright is transfered to the FSF, the 
>> non-exclusive license they grant back to the contributors code should go 
>> to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
>> copyright assignment with the FSF.
>> Thus, in order to ensure this is possible (not that i plan on using the 
>> license for anything at the moment), i'm making sure it's clear that the 
>> code contributed was not soley Jiri's.  
>> So, that way, in the future, if I ever cared to license the code to 
>> someone else, or do something with it, I can without someone asserting 
>> it's only the FSF and Jiri's.
> 
> 
> Please be aware, by the way, that if you don't accept the change to the 
> top of the file, i'll be forced to go bug RMS/the FSF about it, as I'm 
> sure they'd want the code correctly identified as well.
> 
> I'm not asking that I be given credit for something I didn't do.  Nor am I 
> attempting to diminish in any way the size,quantity, or quality, of 
> Jiri's contribution.  I am simply requesting that it be properly 
> identified as a derivation of code I wrote.
> 
> It's imperative that the lineage of code be correctly identified (in fact, 
> if GDB had a legal team, it's the first thing they'd do). In most cases, 
> you can determine it from the cvs annotate/the changelogs. However, for 
> new contributions, there is no history.  Since I never sent the code 
> in question to gdb-patches, it also has no record there.
> 
> I only care because I've been getting an increasing number of requests 
> from companies wanting to buy the source code to the C++ debugger I wrote 
> to replace GDB ( Of course, it uses a variant of the code in question to 
> read/execute frame ops).  I blanket refuse such requests in the hopes that 
> they'll take the money and pay for GDB work instead, but it's something 
> i'd consider if times ever  got really tough.  If there is one thing 
> having three rabbits (rabbits  can't learn through negative reinforcement. 
> i.e. reprimanding them after they have done something wrong does no good) 
> as pets has taught me, it's that it's much easier to make sure a situation 
> never happens, than it is to try to do something about it when it 
> occurs.
> 
> It's not just me, either.  If Jiri/SuSE wanted to license the code to 
> someone, he/they  might accidently sign something saying he was the sole 
> author, which could make him/them liable, etc.
> 
> In short, i'm simply trying to eliminate something that could come back to 
> bite me, or others, in the ass, later.
> 
> If you really want proof it's my code, I can happily provide this as well.
> 
> Since I know you get bogged down in mail, i'll give you till the end of 
> the month before I go bug RMS and the FSF about this.
> 
> --Dan
> 
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:

> > On Mon, 25 Mar 2002, Andrew Cagney wrote:
> > 
> > 
> >> > This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> >> > that doesn't require the CFA context. It also adds code so that when the 
> >> > context passed to execute_stack_op is NULL, we use read_register_gen to 
> >> > get registers.
> > 
> >> 
> >> Hmm, where are you going here?
> > 
> > 
> > Um, rather than have multiple dwarf2 stack op executors, have one.
> > In order to do this, it needs to not require CFA context to be able to 
> > read registers.  
> 
> Shouldn't the dwarf2 location expression evaluator be separated out 
> (dwarf2loc?) and be parameterized with both the frame it is to operate 
> within and the expression it is to evaluate. 

Yeah, so?
I'm doing this incrementally.
The first step is adding an external entry point, then moving it outside 
of dwarf2cfi.c, then modifying it to take a struct frame info, etc.
I'm trying to do this without breaking anything.
It currently *is* parameterized with both the frame and expression.  The 
problem is that the frame it expects isn't a "struct frame_info", it's a 
dwarf2 frame context.

> If the expression 
> evaluator needs the value of a register from the frame it just calls 
> whatever the frame-get-reg-value(frame) function is.
> 
> Andrew
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:

> [I'm sure Richard Stallman doesn't want to be dragged into such an 
> exchange, however]
> 
> Given there is currently a dispute over the origins of the file 
> dwarf2cfi.c, I'm removing it from GDB.

This doesn't make much sense, since of course, both of us have valid 
copyright assignments with the FSF.

> 
> Once that dispute has been resolved, the file can, again be accepted.
> 
> I should note that resolving this will likely take time - Jiri is 
> currently uncontactable, so I'm going to to have to try to follow this 
> up with his peers.

Ask Jan Hubicka (jh@suse.cz), as he asked me to send the code to Jiri.

> 
> sigh,
> Andrew
> 
> > I also added my name to the top of the file, since in reality, it's based 
> >> > > on code I sent Jiri.
> > 
> >> > 
> >> > I'd let Jiri make that decision.
> > 
> >> No.
> >> This is not his decision to make.
> >> A lot of it is my code, unchanged (you can check the x86-64.org 
> >> repository, for the huge change that replaced his code with mine)
> >> He never gave me any credit when he contributed it, for some reason, 
> >> probably because I never asked for it.
> >> I've still got the email I sent him when he asked for the code, and i'm 
> >> sure he'd be happy to confirm he used it.
> >> 
> >> >From a legal standpoint, while the copyright is transfered to the FSF, the 
> >> non-exclusive license they grant back to the contributors code should go 
> >> to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
> >> copyright assignment with the FSF.
> >> Thus, in order to ensure this is possible (not that i plan on using the 
> >> license for anything at the moment), i'm making sure it's clear that the 
> >> code contributed was not soley Jiri's.  
> >> So, that way, in the future, if I ever cared to license the code to 
> >> someone else, or do something with it, I can without someone asserting 
> >> it's only the FSF and Jiri's.
> > 
> > 
> > Please be aware, by the way, that if you don't accept the change to the 
> > top of the file, i'll be forced to go bug RMS/the FSF about it, as I'm 
> > sure they'd want the code correctly identified as well.
> > 
> > I'm not asking that I be given credit for something I didn't do.  Nor am I 
> > attempting to diminish in any way the size,quantity, or quality, of 
> > Jiri's contribution.  I am simply requesting that it be properly 
> > identified as a derivation of code I wrote.
> > 
> > It's imperative that the lineage of code be correctly identified (in fact, 
> > if GDB had a legal team, it's the first thing they'd do). In most cases, 
> > you can determine it from the cvs annotate/the changelogs. However, for 
> > new contributions, there is no history.  Since I never sent the code 
> > in question to gdb-patches, it also has no record there.
> > 
> > I only care because I've been getting an increasing number of requests 
> > from companies wanting to buy the source code to the C++ debugger I wrote 
> > to replace GDB ( Of course, it uses a variant of the code in question to 
> > read/execute frame ops).  I blanket refuse such requests in the hopes that 
> > they'll take the money and pay for GDB work instead, but it's something 
> > i'd consider if times ever  got really tough.  If there is one thing 
> > having three rabbits (rabbits  can't learn through negative reinforcement. 
> > i.e. reprimanding them after they have done something wrong does no good) 
> > as pets has taught me, it's that it's much easier to make sure a situation 
> > never happens, than it is to try to do something about it when it 
> > occurs.
> > 
> > It's not just me, either.  If Jiri/SuSE wanted to license the code to 
> > someone, he/they  might accidently sign something saying he was the sole 
> > author, which could make him/them liable, etc.
> > 
> > In short, i'm simply trying to eliminate something that could come back to 
> > bite me, or others, in the ass, later.
> > 
> > If you really want proof it's my code, I can happily provide this as well.
> > 
> > Since I know you get bogged down in mail, i'll give you till the end of 
> > the month before I go bug RMS and the FSF about this.
> > 
> > --Dan
> > 
> > 
> > 
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:

Allow me to summarize.

1. Both Jiri, and I, have valid copyright assignments. 
2. There is no question the FSF owns the copyright on this code, 
regardless of whether it is my derived work or not. 
3. Thus, it's puzzling that Andrew would remove it, and in fact, seems 
reactionary and unhelpful.
4. The code in question is based on code I sent Jiri, but had never sent 
to gdb-patches. 
5. I knew Jiri would contribute it eventually, and have no problem with 
that.
6. My only concerns are as follows:

	1. The code is not marked as being derived from my work, when I 
can prove it is. (for those who question this, simply look at the dwarf2 
evaluator i sent to the mailing list many moons ago, and you'll see it is 
exactly the execute_stack_op Jiri contributed, with calls to abort() 
changed to internal_error, and a few small other changes I had made later.  
The other pieces of the code, were, as i said, never sent to the mailing 
list).
	2. I use this code in other projects of mine.
	3. The FSF assignments authorize me to request a non-exclusive 
	license from the FSF  upon 30 days written notice. 
	4. I may have a need to request this license at some point in the 
	future.	
	5. I do not wish to have trouble later on acquiring this license 
due to someone at the FSF, or elsewhere, claiming it's not my code, because it 
has no markings that identify as such.
	6. I do not wish to have trouble later on with someone claiming 
the code in some product of mine (or someone else's product, if i licensed 
the code to someone else) is really Jiri's.

As a result, I requested that a single line ("Based on code originally 
written by Daniel Berlin <dan@dberlin.org>") be added to the top of the 
file, stating that it is based originally on code I wrote.  This was to 
avoid any confusion as to the origins of pieces of the code.

I am not asserting that Jiri wrote no portion of the code, and not 
asserting that he didn't make changes to the portions i sent him.  
Certainly, he did.  I'm thus not trying to devalue his contribution in any 
way.  I'm simply trying to avoid a problem in the future asserting that 
code I originally wrote, or work based on that code, is indeed, code I 
wrote, or work based on that code.

This is a simple matter, and one that should *not* be requiring this type 
of argument.  Almost all the code i've sent to gdb-patches, ever, is 
related to DWARF2 debugging support. Portions of the code are 
still basically identical to code I *have* sent to gdb-patches (though 
some large portions were never sent there).  Jiri has never claimed he 
wrote all the code, only that he contributed it.  I've also mentioned 
before that the code in question is based on my work, no one has 
disagreed. Thus, I'm not sure why Andrew feels the need to remove to it 
(since clearly, it's covered by an FSF assignment, both mine, and Jiri's), 
or to make a big deal out  of me adding such a line to the top of the 
file.  It's not as if i am  trying to usurp code that isn't mine. Or 
trying to claim that the FSF has no rights to the code.  Rather than 
simply let the change be made, and be done with it, he felt the 
urge to assert that it was Jiri's decision to mention whether the code is 
based on work originally by me or not. I disagree. The lineage of code 
should be clearly identified, precisely to prevent the kinds of problems i 
mentioned as my concerns.  In effect, Andrew's decision to assert this 
only makes my concerns larger that it is believed to be solely Jiri's 
code, when it is indeed not.  

--Dan 

 > [I'm sure Richard 
Stallman doesn't want to be dragged into such an > exchange, however]
> 
> Given there is currently a dispute over the origins of the file 
> dwarf2cfi.c, I'm removing it from GDB.
> 
> Once that dispute has been resolved, the file can, again be accepted.
> 
> I should note that resolving this will likely take time - Jiri is 
> currently uncontactable, so I'm going to to have to try to follow this 
> up with his peers.
> 
> sigh,
> Andrew
> 
> > I also added my name to the top of the file, since in reality, it's based 
> >> > > on code I sent Jiri.
> > 
> >> > 
> >> > I'd let Jiri make that decision.
> > 
> >> No.
> >> This is not his decision to make.
> >> A lot of it is my code, unchanged (you can check the x86-64.org 
> >> repository, for the huge change that replaced his code with mine)
> >> He never gave me any credit when he contributed it, for some reason, 
> >> probably because I never asked for it.
> >> I've still got the email I sent him when he asked for the code, and i'm 
> >> sure he'd be happy to confirm he used it.
> >> 
> >> >From a legal standpoint, while the copyright is transfered to the FSF, the 
> >> non-exclusive license they grant back to the contributors code should go 
> >> to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
> >> copyright assignment with the FSF.
> >> Thus, in order to ensure this is possible (not that i plan on using the 
> >> license for anything at the moment), i'm making sure it's clear that the 
> >> code contributed was not soley Jiri's.  
> >> So, that way, in the future, if I ever cared to license the code to 
> >> someone else, or do something with it, I can without someone asserting 
> >> it's only the FSF and Jiri's.
> > 
> > 
> > Please be aware, by the way, that if you don't accept the change to the 
> > top of the file, i'll be forced to go bug RMS/the FSF about it, as I'm 
> > sure they'd want the code correctly identified as well.
> > 
> > I'm not asking that I be given credit for something I didn't do.  Nor am I 
> > attempting to diminish in any way the size,quantity, or quality, of 
> > Jiri's contribution.  I am simply requesting that it be properly 
> > identified as a derivation of code I wrote.
> > 
> > It's imperative that the lineage of code be correctly identified (in fact, 
> > if GDB had a legal team, it's the first thing they'd do). In most cases, 
> > you can determine it from the cvs annotate/the changelogs. However, for 
> > new contributions, there is no history.  Since I never sent the code 
> > in question to gdb-patches, it also has no record there.
> > 
> > I only care because I've been getting an increasing number of requests 
> > from companies wanting to buy the source code to the C++ debugger I wrote 
> > to replace GDB ( Of course, it uses a variant of the code in question to 
> > read/execute frame ops).  I blanket refuse such requests in the hopes that 
> > they'll take the money and pay for GDB work instead, but it's something 
> > i'd consider if times ever  got really tough.  If there is one thing 
> > having three rabbits (rabbits  can't learn through negative reinforcement. 
> > i.e. reprimanding them after they have done something wrong does no good) 
> > as pets has taught me, it's that it's much easier to make sure a situation 
> > never happens, than it is to try to do something about it when it 
> > occurs.
> > 
> > It's not just me, either.  If Jiri/SuSE wanted to license the code to 
> > someone, he/they  might accidently sign something saying he was the sole 
> > author, which could make him/them liable, etc.
> > 
> > In short, i'm simply trying to eliminate something that could come back to 
> > bite me, or others, in the ass, later.
> > 
> > If you really want proof it's my code, I can happily provide this as well.
> > 
> > Since I know you get bogged down in mail, i'll give you till the end of 
> > the month before I go bug RMS and the FSF about this.
> > 
> > --Dan
> > 
> > 
> > 
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

The patch looks fine to me.

In the long run, I think it would be nice if the location expression
interpreter took pointers to functions for reading registers and
memory.  Then it could be used with frames, contexts, or whatever.
But as you say --- small incremental changes are fine.

(Regarding authorship: when Jiri's original patch was accepted, Daniel
did jump in and mention that the code was originally his.  I think
it's fine to accept the authorship comment tentatively, until whatever
questions people have have been addressed.)


Daniel Berlin <dan@dberlin.org> writes:

> This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> that doesn't require the CFA context. It also adds code so that when the 
> context passed to execute_stack_op is NULL, we use read_register_gen to 
> get registers.
> 
> Along the way, I made an obvious fix to DW_OP_deref_size that i'll commit 
> separately, but included in the changelog/patch because i didn't want to 
> hand edit it out.
> 
> 
> I also added my name to the top of the file, since in reality, it's based 
> on code I sent Jiri.
> 
> --Dan
> 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> 
> 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> 	entry point to execute_stack_op that doesn't require context.
> 	(execute_stack_op): If context is NULL, don't use get_reg, use
> 	read_register_gen.
>         Also fix bug in DW_OP_deref_size.
> 
> 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> Index: dwarf2cfi.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2cfi.c,v
> retrieving revision 1.1
> diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.c
> *** dwarf2cfi.c	2001/12/07 12:10:15	1.1
> --- dwarf2cfi.c	2002/03/25 23:50:16
> ***************
> *** 1,7 ****
>   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> !    Copyright 2001
>      Free Software Foundation, Inc.
>      Contributed by Jiri Smid, SuSE Labs.
>   
>      This file is part of GDB.
>   
> --- 1,8 ----
>   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> !    Copyright 2001, 2002
>      Free Software Foundation, Inc.
>      Contributed by Jiri Smid, SuSE Labs.
> +    Based on code written by Daniel Berlin (dan@dberlin.org)
>   
>      This file is part of GDB.
>   
> *************** get_reg (char *reg, struct context *cont
> *** 840,845 ****
> --- 841,854 ----
>       }
>   }
>   
> + /* External entry point for executing dwarf2 stack operations. */
> + CORE_ADDR
> + dwarf2_execute_stack_op (struct objfile *objfile, char *op_ptr,
> + 			 char *op_end, CORE_ADDR initial)
> + {
> +   return execute_stack_op (objfile, op_ptr, op_end, NULL, initial);
> + }
> + 
>   /* Decode a DW_OP stack program.  Return the top of stack.  Push INITIAL
>      onto the stack to start.  */
>   static CORE_ADDR
> *************** execute_stack_op (struct objfile *objfil
> *** 963,973 ****
> --- 972,989 ----
>   	case DW_OP_reg29:
>   	case DW_OP_reg30:
>   	case DW_OP_reg31:
> + 	  if (context)
>   	    get_reg ((char *) &result, context, op - DW_OP_reg0);
> + 	  else
> + 	    read_register_gen (op - DW_OP_reg0, (char *)&result);
> + 	  
>   	  break;
>   	case DW_OP_regx:
>   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, reg);
> + 	  else
> + 	    read_register_gen (reg, (char *)&result);
>   	  break;
>   
>   	case DW_OP_breg0:
> *************** execute_stack_op (struct objfile *objfil
> *** 1003,1015 ****
> --- 1019,1038 ----
>   	case DW_OP_breg30:
>   	case DW_OP_breg31:
>   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, op - DW_OP_breg0);
> + 	  else
> + 	    read_register_gen (op - DW_OP_breg0, (char *)&result);
> + 	  
>   	  result += offset;
>   	  break;
>   	case DW_OP_bregx:
>   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
>   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, reg);
> + 	  else
> + 	    read_register_gen (reg, (char *)&result);
>   	  result += offset;
>   	  break;
>   
> *************** execute_stack_op (struct objfile *objfil
> *** 1067,1080 ****
>   	    {
>   	    case DW_OP_deref:
>   	      {
> ! 		char *ptr = (char *) result;
>   		result = read_pointer (objfile->obfd, &ptr);
>   	      }
>   	      break;
>   
>   	    case DW_OP_deref_size:
>   	      {
> ! 		char *ptr = (char *) result;
>   		switch (*op_ptr++)
>   		  {
>   		  case 1:
> --- 1090,1103 ----
>   	    {
>   	    case DW_OP_deref:
>   	      {
> ! 		char *ptr = (char *) &result;
>   		result = read_pointer (objfile->obfd, &ptr);
>   	      }
>   	      break;
>   
>   	    case DW_OP_deref_size:
>   	      {
> ! 		char *ptr = (char *) &result;
>   		switch (*op_ptr++)
>   		  {
>   		  case 1:
> Index: dwarf2cfi.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2cfi.h,v
> retrieving revision 1.1
> diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.h
> *** dwarf2cfi.h	2001/12/07 12:10:15	1.1
> --- dwarf2cfi.h	2002/03/25 23:50:16
> *************** void cfi_get_saved_register (char *raw_b
> *** 63,66 ****
> --- 63,72 ----
>   void cfi_virtual_frame_pointer (CORE_ADDR pc, int *frame_regnum,
>   				LONGEST * frame_offset);
>   
> + /*  Execute a set of DWARF2 stack operations, starting with INITIAL
> +     as the address on the stack. */
> + CORE_ADDR dwarf2_execute_stack_op (struct objfile *objfile, 
> + 				   char *op_ptr, char *op_end,
> + 				   CORE_ADDR initial);
> + 
>   #endif
> Index: ChangeLog
> ===================================================================
> RCS file: /cvs/src/src/gdb/ChangeLog,v
> retrieving revision 1.2349
> diff -c -3 -p -w -B -b -r1.2349 ChangeLog
> *** ChangeLog	2002/03/25 19:47:39	1.2349
> --- ChangeLog	2002/03/25 23:50:17
> ***************
> *** 1,3 ****
> --- 1,12 ----
> + 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> + 
> + 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> + 	entry point to execute_stack_op that doesn't require context.
> + 	(execute_stack_op): If context is NULL, don't use get_reg, use
> + 	read_register_gen.
> + 
> + 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> + 
>   2002-03-25  Jeff Law (law@redhat.com)
>   
>   	* linux-proc.c (read_mapping): Scan up to end of line for filename.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andreas Jaeger]

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

Daniel Berlin <dan@dberlin.org> writes:

> On Tue, 26 Mar 2002, Andrew Cagney wrote:
>
> Allow me to summarize.

Daniel, sorry that this situation arose.

>
> 1. Both Jiri, and I, have valid copyright assignments. 
> 2. There is no question the FSF owns the copyright on this code, 
> regardless of whether it is my derived work or not. 
> 3. Thus, it's puzzling that Andrew would remove it, and in fact, seems 
> reactionary and unhelpful.
> 4. The code in question is based on code I sent Jiri, but had never sent 
> to gdb-patches. 
> 5. I knew Jiri would contribute it eventually, and have no problem with 
> that.
> 6. My only concerns are as follows:

Please accept my apologies that this happened. Jiri is doing his
military service now and therefore not available for questions and
comments.  I believe your claims above since I told Jiri to get in
contact with you regarding your work on dwarf2 unwinding.

> 	1. The code is not marked as being derived from my work, when I 
> can prove it is. (for those who question this, simply look at the dwarf2 

I do not questions this.  I have every reason to believe you.

> evaluator i sent to the mailing list many moons ago, and you'll see it is 
> exactly the execute_stack_op Jiri contributed, with calls to abort() 
> changed to internal_error, and a few small other changes I had made later.  
> The other pieces of the code, were, as i said, never sent to the mailing 
> list).
> 	2. I use this code in other projects of mine.
> 	3. The FSF assignments authorize me to request a non-exclusive 
> 	license from the FSF  upon 30 days written notice. 
> 	4. I may have a need to request this license at some point in the 
> 	future.	
> 	5. I do not wish to have trouble later on acquiring this license 
> due to someone at the FSF, or elsewhere, claiming it's not my code, because it 
> has no markings that identify as such.
> 	6. I do not wish to have trouble later on with someone claiming 
> the code in some product of mine (or someone else's product, if i licensed 
> the code to someone else) is really Jiri's.
>
> As a result, I requested that a single line ("Based on code originally 
> written by Daniel Berlin <dan@dberlin.org>") be added to the top of the 
> file, stating that it is based originally on code I wrote.  This was to 
> avoid any confusion as to the origins of pieces of the code.

Since Jiri is not available now, I'd like to emphasize that I'm fine
with this patch and would suggest to get it added to CVS.

> I am not asserting that Jiri wrote no portion of the code, and not 
> asserting that he didn't make changes to the portions i sent him.  
> Certainly, he did.  I'm thus not trying to devalue his contribution in any 
> way.  I'm simply trying to avoid a problem in the future asserting that 
> code I originally wrote, or work based on that code, is indeed, code I 
> wrote, or work based on that code.

I agree that credit should be given to those people that worked on the
code - in this case Jiri and yourself.

> This is a simple matter, and one that should *not* be requiring this type 
> of argument.  Almost all the code i've sent to gdb-patches, ever, is 
> related to DWARF2 debugging support. Portions of the code are 
> still basically identical to code I *have* sent to gdb-patches (though 
> some large portions were never sent there).  Jiri has never claimed he 
> wrote all the code, only that he contributed it.  I've also mentioned 
> before that the code in question is based on my work, no one has 
> disagreed. Thus, I'm not sure why Andrew feels the need to remove to it 
> (since clearly, it's covered by an FSF assignment, both mine, and Jiri's), 
> or to make a big deal out  of me adding such a line to the top of the 
> file.  It's not as if i am  trying to usurp code that isn't mine. Or 
> trying to claim that the FSF has no rights to the code.  Rather than 
> simply let the change be made, and be done with it, he felt the 
> urge to assert that it was Jiri's decision to mention whether the code is 
> based on work originally by me or not. I disagree. The lineage of code 
> should be clearly identified, precisely to prevent the kinds of problems i 
> mentioned as my concerns.  In effect, Andrew's decision to assert this 
> only makes my concerns larger that it is believed to be solely Jiri's 
> code, when it is indeed not.  

Daniel, I do believe you that it's not solely your code.  I do not
know how much of the code is yours and what is Jiri's work but I do
think that you laid the basis for the current code and therefore
you're co-author of this code.

Let me assure that it's not SuSE intent to hijack somebody else's
code.

I hope this clarifies the situation and the code can be added back to
the repository together with both names on it,

Andreas Jaeger
SuSE Labs

>
> --Dan 
>
>  > [I'm sure Richard 
> Stallman doesn't want to be dragged into such an > exchange, however]
>> 
>> Given there is currently a dispute over the origins of the file 
>> dwarf2cfi.c, I'm removing it from GDB.
>> 
>> Once that dispute has been resolved, the file can, again be accepted.
>> 
>> I should note that resolving this will likely take time - Jiri is 
>> currently uncontactable, so I'm going to to have to try to follow this 
>> up with his peers.
>> 
>> sigh,
>> Andrew
>> 
>> > I also added my name to the top of the file, since in reality, it's based 
>> >> > > on code I sent Jiri.
>> > 
>> >> > 
>> >> > I'd let Jiri make that decision.
>> > 
>> >> No.
>> >> This is not his decision to make.
>> >> A lot of it is my code, unchanged (you can check the x86-64.org 
>> >> repository, for the huge change that replaced his code with mine)
>> >> He never gave me any credit when he contributed it, for some reason, 
>> >> probably because I never asked for it.
>> >> I've still got the email I sent him when he asked for the code, and i'm 
>> >> sure he'd be happy to confirm he used it.
>> >> 
>> >> >From a legal standpoint, while the copyright is transfered to the FSF, the 
>> >> non-exclusive license they grant back to the contributors code should go 
>> >> to me as well as Jiri, not just to Jiri.  This is part of of the contract of the 
>> >> copyright assignment with the FSF.
>> >> Thus, in order to ensure this is possible (not that i plan on using the 
>> >> license for anything at the moment), i'm making sure it's clear that the 
>> >> code contributed was not soley Jiri's.  
>> >> So, that way, in the future, if I ever cared to license the code to 
>> >> someone else, or do something with it, I can without someone asserting 
>> >> it's only the FSF and Jiri's.
>> > 
>> > 
>> > Please be aware, by the way, that if you don't accept the change to the 
>> > top of the file, i'll be forced to go bug RMS/the FSF about it, as I'm 
>> > sure they'd want the code correctly identified as well.
>> > 
>> > I'm not asking that I be given credit for something I didn't do.  Nor am I 
>> > attempting to diminish in any way the size,quantity, or quality, of 
>> > Jiri's contribution.  I am simply requesting that it be properly 
>> > identified as a derivation of code I wrote.
>> > 
>> > It's imperative that the lineage of code be correctly identified (in fact, 
>> > if GDB had a legal team, it's the first thing they'd do). In most cases, 
>> > you can determine it from the cvs annotate/the changelogs. However, for 
>> > new contributions, there is no history.  Since I never sent the code 
>> > in question to gdb-patches, it also has no record there.
>> > 
>> > I only care because I've been getting an increasing number of requests 
>> > from companies wanting to buy the source code to the C++ debugger I wrote 
>> > to replace GDB ( Of course, it uses a variant of the code in question to 
>> > read/execute frame ops).  I blanket refuse such requests in the hopes that 
>> > they'll take the money and pay for GDB work instead, but it's something 
>> > i'd consider if times ever  got really tough.  If there is one thing 
>> > having three rabbits (rabbits  can't learn through negative reinforcement. 
>> > i.e. reprimanding them after they have done something wrong does no good) 
>> > as pets has taught me, it's that it's much easier to make sure a situation 
>> > never happens, than it is to try to do something about it when it 
>> > occurs.
>> > 
>> > It's not just me, either.  If Jiri/SuSE wanted to license the code to 
>> > someone, he/they  might accidently sign something saying he was the sole 
>> > author, which could make him/them liable, etc.
>> > 
>> > In short, i'm simply trying to eliminate something that could come back to 
>> > bite me, or others, in the ass, later.
>> > 
>> > If you really want proof it's my code, I can happily provide this as well.
>> > 
>> > Since I know you get bogged down in mail, i'll give you till the end of 
>> > the month before I go bug RMS and the FSF about this.
>> > 
>> > --Dan
>> > 
>> > 
>> > 
>> 
>> 
>

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

Actually, Daniel, I'm sorry --- I've re-read the change more
carefully, and I've gotten more confused than I was before.

You've changed the Dwarf 2 location expression evaluator to consult
the current register values --- not the values of the registers with
respect to a specific stack frame.  I can't think of any situations in
which this the correct behavior.  Can you explain more about the
contexts in which this change is useful?  It seems to me that it's
wrong in most of the cases I can think of.  It really needs to take a
frame argument, or at the very least, read registers from the selected
frame (although that's kind of gross and global-variable-ish).


Daniel Berlin <dan@dberlin.org> writes:

> This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> that doesn't require the CFA context. It also adds code so that when the 
> context passed to execute_stack_op is NULL, we use read_register_gen to 
> get registers.
> 
> Along the way, I made an obvious fix to DW_OP_deref_size that i'll commit 
> separately, but included in the changelog/patch because i didn't want to 
> hand edit it out.
> 
> 
> I also added my name to the top of the file, since in reality, it's based 
> on code I sent Jiri.
> 
> --Dan
> 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> 
> 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> 	entry point to execute_stack_op that doesn't require context.
> 	(execute_stack_op): If context is NULL, don't use get_reg, use
> 	read_register_gen.
>         Also fix bug in DW_OP_deref_size.
> 
> 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> Index: dwarf2cfi.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2cfi.c,v
> retrieving revision 1.1
> diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.c
> *** dwarf2cfi.c	2001/12/07 12:10:15	1.1
> --- dwarf2cfi.c	2002/03/25 23:50:16
> ***************
> *** 1,7 ****
>   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> !    Copyright 2001
>      Free Software Foundation, Inc.
>      Contributed by Jiri Smid, SuSE Labs.
>   
>      This file is part of GDB.
>   
> --- 1,8 ----
>   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> !    Copyright 2001, 2002
>      Free Software Foundation, Inc.
>      Contributed by Jiri Smid, SuSE Labs.
> +    Based on code written by Daniel Berlin (dan@dberlin.org)
>   
>      This file is part of GDB.
>   
> *************** get_reg (char *reg, struct context *cont
> *** 840,845 ****
> --- 841,854 ----
>       }
>   }
>   
> + /* External entry point for executing dwarf2 stack operations. */
> + CORE_ADDR
> + dwarf2_execute_stack_op (struct objfile *objfile, char *op_ptr,
> + 			 char *op_end, CORE_ADDR initial)
> + {
> +   return execute_stack_op (objfile, op_ptr, op_end, NULL, initial);
> + }
> + 
>   /* Decode a DW_OP stack program.  Return the top of stack.  Push INITIAL
>      onto the stack to start.  */
>   static CORE_ADDR
> *************** execute_stack_op (struct objfile *objfil
> *** 963,973 ****
> --- 972,989 ----
>   	case DW_OP_reg29:
>   	case DW_OP_reg30:
>   	case DW_OP_reg31:
> + 	  if (context)
>   	    get_reg ((char *) &result, context, op - DW_OP_reg0);
> + 	  else
> + 	    read_register_gen (op - DW_OP_reg0, (char *)&result);
> + 	  
>   	  break;
>   	case DW_OP_regx:
>   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, reg);
> + 	  else
> + 	    read_register_gen (reg, (char *)&result);
>   	  break;
>   
>   	case DW_OP_breg0:
> *************** execute_stack_op (struct objfile *objfil
> *** 1003,1015 ****
> --- 1019,1038 ----
>   	case DW_OP_breg30:
>   	case DW_OP_breg31:
>   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, op - DW_OP_breg0);
> + 	  else
> + 	    read_register_gen (op - DW_OP_breg0, (char *)&result);
> + 	  
>   	  result += offset;
>   	  break;
>   	case DW_OP_bregx:
>   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
>   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> + 	  if (context)
>   	    get_reg ((char *) &result, context, reg);
> + 	  else
> + 	    read_register_gen (reg, (char *)&result);
>   	  result += offset;
>   	  break;
>   
> *************** execute_stack_op (struct objfile *objfil
> *** 1067,1080 ****
>   	    {
>   	    case DW_OP_deref:
>   	      {
> ! 		char *ptr = (char *) result;
>   		result = read_pointer (objfile->obfd, &ptr);
>   	      }
>   	      break;
>   
>   	    case DW_OP_deref_size:
>   	      {
> ! 		char *ptr = (char *) result;
>   		switch (*op_ptr++)
>   		  {
>   		  case 1:
> --- 1090,1103 ----
>   	    {
>   	    case DW_OP_deref:
>   	      {
> ! 		char *ptr = (char *) &result;
>   		result = read_pointer (objfile->obfd, &ptr);
>   	      }
>   	      break;
>   
>   	    case DW_OP_deref_size:
>   	      {
> ! 		char *ptr = (char *) &result;
>   		switch (*op_ptr++)
>   		  {
>   		  case 1:
> Index: dwarf2cfi.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2cfi.h,v
> retrieving revision 1.1
> diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.h
> *** dwarf2cfi.h	2001/12/07 12:10:15	1.1
> --- dwarf2cfi.h	2002/03/25 23:50:16
> *************** void cfi_get_saved_register (char *raw_b
> *** 63,66 ****
> --- 63,72 ----
>   void cfi_virtual_frame_pointer (CORE_ADDR pc, int *frame_regnum,
>   				LONGEST * frame_offset);
>   
> + /*  Execute a set of DWARF2 stack operations, starting with INITIAL
> +     as the address on the stack. */
> + CORE_ADDR dwarf2_execute_stack_op (struct objfile *objfile, 
> + 				   char *op_ptr, char *op_end,
> + 				   CORE_ADDR initial);
> + 
>   #endif
> Index: ChangeLog
> ===================================================================
> RCS file: /cvs/src/src/gdb/ChangeLog,v
> retrieving revision 1.2349
> diff -c -3 -p -w -B -b -r1.2349 ChangeLog
> *** ChangeLog	2002/03/25 19:47:39	1.2349
> --- ChangeLog	2002/03/25 23:50:17
> ***************
> *** 1,3 ****
> --- 1,12 ----
> + 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> + 
> + 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> + 	entry point to execute_stack_op that doesn't require context.
> + 	(execute_stack_op): If context is NULL, don't use get_reg, use
> + 	read_register_gen.
> + 
> + 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> + 
>   2002-03-25  Jeff Law (law@redhat.com)
>   
>   	* linux-proc.c (read_mapping): Scan up to end of line for filename.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 26 Mar 2002, Jim Blandy wrote:

> 
> Actually, Daniel, I'm sorry --- I've re-read the change more
> carefully, and I've gotten more confused than I was before.
> 
> You've changed the Dwarf 2 location expression evaluator to consult
> the current register values --- not the values of the registers with
> respect to a specific stack frame.  I can't think of any situations in
> which this the correct behavior.  Can you explain more about the
> contexts in which this change is useful?  It seems to me that it's
> wrong in most of the cases I can think of.  It really needs to take a
> frame argument, or at the very least, read registers from the selected
> frame (although that's kind of gross and global-variable-ish).

Whoops.
You're right.
I must have merged it while on crack or something.
I *meant* to add the frame argument, and only require *either* the 
context argument (Which is what it currently takes, a CFA context)  or the 
frame, but it looks like I messed up.

What it *should* look like is closer to the one from the WIP i sent. It 
should call get_saved_register with the frame argument if the context is 
null, or get_reg with the context argument if the context is not null.


> 
> 
> Daniel Berlin <dan@dberlin.org> writes:
> 
> > This patch simply adds an external entry point (dwarf2_execute_stack_op), 
> > that doesn't require the CFA context. It also adds code so that when the 
> > context passed to execute_stack_op is NULL, we use read_register_gen to 
> > get registers.
> > 
> > Along the way, I made an obvious fix to DW_OP_deref_size that i'll commit 
> > separately, but included in the changelog/patch because i didn't want to 
> > hand edit it out.
> > 
> > 
> > I also added my name to the top of the file, since in reality, it's based 
> > on code I sent Jiri.
> > 
> > --Dan
> > 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> > 
> > 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> > 	entry point to execute_stack_op that doesn't require context.
> > 	(execute_stack_op): If context is NULL, don't use get_reg, use
> > 	read_register_gen.
> >         Also fix bug in DW_OP_deref_size.
> > 
> > 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> > Index: dwarf2cfi.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dwarf2cfi.c,v
> > retrieving revision 1.1
> > diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.c
> > *** dwarf2cfi.c	2001/12/07 12:10:15	1.1
> > --- dwarf2cfi.c	2002/03/25 23:50:16
> > ***************
> > *** 1,7 ****
> >   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> > !    Copyright 2001
> >      Free Software Foundation, Inc.
> >      Contributed by Jiri Smid, SuSE Labs.
> >   
> >      This file is part of GDB.
> >   
> > --- 1,8 ----
> >   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> > !    Copyright 2001, 2002
> >      Free Software Foundation, Inc.
> >      Contributed by Jiri Smid, SuSE Labs.
> > +    Based on code written by Daniel Berlin (dan@dberlin.org)
> >   
> >      This file is part of GDB.
> >   
> > *************** get_reg (char *reg, struct context *cont
> > *** 840,845 ****
> > --- 841,854 ----
> >       }
> >   }
> >   
> > + /* External entry point for executing dwarf2 stack operations. */
> > + CORE_ADDR
> > + dwarf2_execute_stack_op (struct objfile *objfile, char *op_ptr,
> > + 			 char *op_end, CORE_ADDR initial)
> > + {
> > +   return execute_stack_op (objfile, op_ptr, op_end, NULL, initial);
> > + }
> > + 
> >   /* Decode a DW_OP stack program.  Return the top of stack.  Push INITIAL
> >      onto the stack to start.  */
> >   static CORE_ADDR
> > *************** execute_stack_op (struct objfile *objfil
> > *** 963,973 ****
> > --- 972,989 ----
> >   	case DW_OP_reg29:
> >   	case DW_OP_reg30:
> >   	case DW_OP_reg31:
> > + 	  if (context)
> >   	    get_reg ((char *) &result, context, op - DW_OP_reg0);
> > + 	  else
> > + 	    read_register_gen (op - DW_OP_reg0, (char *)&result);
> > + 	  
> >   	  break;
> >   	case DW_OP_regx:
> >   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
> > + 	  if (context)
> >   	    get_reg ((char *) &result, context, reg);
> > + 	  else
> > + 	    read_register_gen (reg, (char *)&result);
> >   	  break;
> >   
> >   	case DW_OP_breg0:
> > *************** execute_stack_op (struct objfile *objfil
> > *** 1003,1015 ****
> > --- 1019,1038 ----
> >   	case DW_OP_breg30:
> >   	case DW_OP_breg31:
> >   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> > + 	  if (context)
> >   	    get_reg ((char *) &result, context, op - DW_OP_breg0);
> > + 	  else
> > + 	    read_register_gen (op - DW_OP_breg0, (char *)&result);
> > + 	  
> >   	  result += offset;
> >   	  break;
> >   	case DW_OP_bregx:
> >   	  reg = read_uleb128 (objfile->obfd, &op_ptr);
> >   	  offset = read_sleb128 (objfile->obfd, &op_ptr);
> > + 	  if (context)
> >   	    get_reg ((char *) &result, context, reg);
> > + 	  else
> > + 	    read_register_gen (reg, (char *)&result);
> >   	  result += offset;
> >   	  break;
> >   
> > *************** execute_stack_op (struct objfile *objfil
> > *** 1067,1080 ****
> >   	    {
> >   	    case DW_OP_deref:
> >   	      {
> > ! 		char *ptr = (char *) result;
> >   		result = read_pointer (objfile->obfd, &ptr);
> >   	      }
> >   	      break;
> >   
> >   	    case DW_OP_deref_size:
> >   	      {
> > ! 		char *ptr = (char *) result;
> >   		switch (*op_ptr++)
> >   		  {
> >   		  case 1:
> > --- 1090,1103 ----
> >   	    {
> >   	    case DW_OP_deref:
> >   	      {
> > ! 		char *ptr = (char *) &result;
> >   		result = read_pointer (objfile->obfd, &ptr);
> >   	      }
> >   	      break;
> >   
> >   	    case DW_OP_deref_size:
> >   	      {
> > ! 		char *ptr = (char *) &result;
> >   		switch (*op_ptr++)
> >   		  {
> >   		  case 1:
> > Index: dwarf2cfi.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dwarf2cfi.h,v
> > retrieving revision 1.1
> > diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.h
> > *** dwarf2cfi.h	2001/12/07 12:10:15	1.1
> > --- dwarf2cfi.h	2002/03/25 23:50:16
> > *************** void cfi_get_saved_register (char *raw_b
> > *** 63,66 ****
> > --- 63,72 ----
> >   void cfi_virtual_frame_pointer (CORE_ADDR pc, int *frame_regnum,
> >   				LONGEST * frame_offset);
> >   
> > + /*  Execute a set of DWARF2 stack operations, starting with INITIAL
> > +     as the address on the stack. */
> > + CORE_ADDR dwarf2_execute_stack_op (struct objfile *objfile, 
> > + 				   char *op_ptr, char *op_end,
> > + 				   CORE_ADDR initial);
> > + 
> >   #endif
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/ChangeLog,v
> > retrieving revision 1.2349
> > diff -c -3 -p -w -B -b -r1.2349 ChangeLog
> > *** ChangeLog	2002/03/25 19:47:39	1.2349
> > --- ChangeLog	2002/03/25 23:50:17
> > ***************
> > *** 1,3 ****
> > --- 1,12 ----
> > + 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> > + 
> > + 	* dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> > + 	entry point to execute_stack_op that doesn't require context.
> > + 	(execute_stack_op): If context is NULL, don't use get_reg, use
> > + 	read_register_gen.
> > + 
> > + 	* dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> > + 
> >   2002-03-25  Jeff Law (law@redhat.com)
> >   
> >   	* linux-proc.c (read_mapping): Scan up to end of line for filename.
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> 
> Whoops.
> You're right.
> I must have merged it while on crack or something.
> I *meant* to add the frame argument, and only require *either* the 
> context argument (Which is what it currently takes, a CFA context)  or the 
> frame, but it looks like I messed up.
> 
> What it *should* look like is closer to the one from the WIP i sent. It 
> should call get_saved_register with the frame argument if the context is 
> null, or get_reg with the context argument if the context is not null.

That is what I was asking

I wrote:

>> Shouldn't the dwarf2 location expression evaluator be separated out 
>> (dwarf2loc?) and be parameterized with both the frame it is to operate 
>> within and the expression it is to evaluate. 

You wrote:

> Yeah, so?
> I'm doing this incrementally.
> The first step is adding an external entry point, then moving it outside 
> of dwarf2cfi.c, then modifying it to take a struct frame info, etc.
> I'm trying to do this without breaking anything.
> It currently *is* parameterized with both the frame and expression.  The 
> problem is that the frame it expects isn't a "struct frame_info", it's a 
> dwarf2 frame context.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

Daniel Berlin <dan@dberlin.org> writes:
> On 26 Mar 2002, Jim Blandy wrote:
> > Actually, Daniel, I'm sorry --- I've re-read the change more
> > carefully, and I've gotten more confused than I was before.
> > 
> > You've changed the Dwarf 2 location expression evaluator to consult
> > the current register values --- not the values of the registers with
> > respect to a specific stack frame.  I can't think of any situations in
> > which this the correct behavior.  Can you explain more about the
> > contexts in which this change is useful?  It seems to me that it's
> > wrong in most of the cases I can think of.  It really needs to take a
> > frame argument, or at the very least, read registers from the selected
> > frame (although that's kind of gross and global-variable-ish).
> 
> Whoops.
> You're right.
> I must have merged it while on crack or something.
> I *meant* to add the frame argument, and only require *either* the 
> context argument (Which is what it currently takes, a CFA context)  or the 
> frame, but it looks like I messed up.
> 
> What it *should* look like is closer to the one from the WIP i sent. It 
> should call get_saved_register with the frame argument if the context is 
> null, or get_reg with the context argument if the context is not null.

Okay --- that makes more sense.

I started reviewing the WIP, but I got interrupted.  Do you want to
extract something from that and post it as a non-WIP patch?

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:
> You wrote:
> 

> > 
> > Whoops.
> > You're right.
> > I must have merged it while on crack or something.
> > I *meant* to add the frame argument, and only require *either* the 
> > context argument (Which is what it currently takes, a CFA context)  or the 
> > frame, but it looks like I messed up.
> > 
> > What it *should* look like is closer to the one from the WIP i sent. It 
> > should call get_saved_register with the frame argument if the context is 
> > null, or get_reg with the context argument if the context is not null.
> 
> That is what I was asking
> 
> I wrote:
> 
> >> Shouldn't the dwarf2 location expression evaluator be separated out 
> >> (dwarf2loc?) and be parameterized with both the frame it is to operate 
> >> within and the expression it is to evaluate. 

> > 
> > Whoops.
> > You're right.
> > I must have merged it while on crack or something.
> > I *meant* to add the frame argument, and only require *either* the 
> > context argument (Which is what it currently takes, a CFA context)  or the 
> > frame, but it looks like I messed up.
> > 
> > What it *should* look like is closer to the one from the WIP i sent. It 
> > should call get_saved_register with the frame argument if the context is 
> > null, or get_reg with the context argument if the context is not null.
> 
> That is what I was asking
> 
> I wrote:
> 
> >> Shouldn't the dwarf2 location expression evaluator be separated out 
> >> (dwarf2loc?) and be parameterized with both the frame it is to operate 
> >> within and the expression it is to evaluate. 
> 

> > 
> > Whoops.
> > You're right.
> > I must have merged it while on crack or something.
> > I *meant* to add the frame argument, and only require *either* the 
> > context argument (Which is what it currently takes, a CFA context)  or the 
> > frame, but it looks like I messed up.
> > 
> > What it *should* look like is closer to the one from the WIP i sent. It 
> > should call get_saved_register with the frame argument if the context is 
> > null, or get_reg with the context argument if the context is not null.
> 
> That is what I was asking

Errr, not really.
What I said is correct.
It is parameterized already with a frame and an expression.
It's just that we want to hand it a different type of frame.

You implied it wasn't parameterized with either, when it has been since 
the beginning.  However, I *meant* to change it to take either a struct 
context (one type of frame), or a struct frame_info. 
I've written this code so many times that I rewrote/merged it without 
thinking, and forgot to add the other type of frame parameter to the 
external entry point.

The only actual changes needed between what I submitted, and what it 
should be, is one more parameter, and changing read_register_gen to 
get_saved_register.

> I wrote:
> 
> >> Shouldn't the dwarf2 location expression evaluator be separated out 
> >> (dwarf2loc?) and be parameterized with both the frame it is to operate 
> >> within and the expression it is to evaluate. 
> 

> 
> > Yeah, so?
> > I'm doing this incrementally.
> > The first step is adding an external entry point, then moving it outside 
> > of dwarf2cfi.c, then modifying it to take a struct frame info, etc.
> > I'm trying to do this without breaking anything.
> > It currently *is* parameterized with both the frame and expression.  The 
> > problem is that the frame it expects isn't a "struct frame_info", it's a 
> > dwarf2 frame context.
> 
> Andrew
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> 
> Errr, not really.
> What I said is correct.
> It is parameterized already with a frame and an expression.
> It's just that we want to hand it a different type of frame.
> 
> You implied it wasn't parameterized with either, when it has been since 
> the beginning.

You're mistaken.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:

> > 
> > Errr, not really.
> > What I said is correct.
> > It is parameterized already with a frame and an expression.
> > It's just that we want to hand it a different type of frame.
> > 
> > You implied it wasn't parameterized with either, when it has been since 
> > the beginning.
> 
> You're mistaken.
On which point?
Have you ever considered that you might have just been unclear?
I had no problem understanding it when Jim wrote it.
For example, replying to two points with "You're mistaken" is in itself 
unclear, as I can't tell if you mean i'm mistaken about the last one, the 
first one, or  both. 

 > 
> Andrew
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andreas Jaeger wrote:

> Daniel Berlin <dan@dberlin.org> writes:
> 
> > On Tue, 26 Mar 2002, Andrew Cagney wrote:
> >
> > Allow me to summarize.
> 
> Daniel, sorry that this situation arose.
Not as much as I am.
The change should have been a non-issue.

> 
> >
> > 1. Both Jiri, and I, have valid copyright assignments. 
> > 2. There is no question the FSF owns the copyright on this code, 
> > regardless of whether it is my derived work or not. 
> > 3. Thus, it's puzzling that Andrew would remove it, and in fact, seems 
> > reactionary and unhelpful.
> > 4. The code in question is based on code I sent Jiri, but had never sent 
> > to gdb-patches. 
> > 5. I knew Jiri would contribute it eventually, and have no problem with 
> > that.
> > 6. My only concerns are as follows:
> 
> Please accept my apologies that this happened. Jiri is doing his
> military service now and therefore not available for questions and
> comments.  I believe your claims above since I told Jiri to get in
> contact with you regarding your work on dwarf2 unwinding.
> 
> > 	1. The code is not marked as being derived from my work, when I 
> > can prove it is. (for those who question this, simply look at the dwarf2 
> 
> I do not questions this.  I have every reason to believe you.
> 
> > evaluator i sent to the mailing list many moons ago, and you'll see it is 
> > exactly the execute_stack_op Jiri contributed, with calls to abort() 
> > changed to internal_error, and a few small other changes I had made later.  
> > The other pieces of the code, were, as i said, never sent to the mailing 
> > list).
> > 	2. I use this code in other projects of mine.
> > 	3. The FSF assignments authorize me to request a non-exclusive 
> > 	license from the FSF  upon 30 days written notice. 
> > 	4. I may have a need to request this license at some point in the 
> > 	future.	
> > 	5. I do not wish to have trouble later on acquiring this license 
> > due to someone at the FSF, or elsewhere, claiming it's not my code, because it 
> > has no markings that identify as such.
> > 	6. I do not wish to have trouble later on with someone claiming 
> > the code in some product of mine (or someone else's product, if i licensed 
> > the code to someone else) is really Jiri's.
> >
> > As a result, I requested that a single line ("Based on code originally 
> > written by Daniel Berlin <dan@dberlin.org>") be added to the top of the 
> > file, stating that it is based originally on code I wrote.  This was to 
> > avoid any confusion as to the origins of pieces of the code.
> 
> Since Jiri is not available now, I'd like to emphasize that I'm fine
> with this patch and would suggest to get it added to CVS.

So would I.
I'll have to get a translator or something.


> > I am not asserting that Jiri wrote no portion of the code, and not 
> > asserting that he didn't make changes to the portions i sent him.  
> > Certainly, he did.  I'm thus not trying to devalue his contribution in any 
> > way.  I'm simply trying to avoid a problem in the future asserting that 
> > code I originally wrote, or work based on that code, is indeed, code I 
> > wrote, or work based on that code.
> 
> I agree that credit should be given to those people that worked on the
> code - in this case Jiri and yourself.

That's fine by me. 
> 
> 
> Daniel, I do believe you that it's not solely your code.  I do not
> know how much of the code is yours and what is Jiri's work but I do
> think that you laid the basis for the current code and therefore
> you're co-author of this code.
> 
> Let me assure that it's not SuSE intent to hijack somebody else's
> code.
Nor have I ever assumed SuSE had any intent.
As far as I'm concerned, it was just a simple oversight by Jiri.
In fact, I considered it such a minor oversight that i didn't even submit 
it as a separate patch, just as i didn't separate out the update of the 
copyright years.
> 
> I hope this clarifies the situation and the code can be added back to
> the repository together with both names on it,
So do I.
The extreme reaction of removing code from the 
repository, simply reminds me why i spend time working on GCC rather than 
GDB, and why i coded a replacement in C++ in the first place.
--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

Richard, sorry about this e-mail exchange.  The problem has been resolved.

	Andrew


> [I'm sure Richard Stallman doesn't want to be dragged into such an exchange, however]
> 
> Given there is currently a dispute over the origins of the file dwarf2cfi.c, I'm removing it from GDB.
> 
> Once that dispute has been resolved, the file can, again be accepted.
> 
> I should note that resolving this will likely take time - Jiri is currently uncontactable, so I'm going to to have to try to follow this up with his peers.
> 
> sigh,
> Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> On Tue, 26 Mar 2002, Andrew Cagney wrote:
> 
> 
>> > 
>> > Errr, not really.
>> > What I said is correct.
>> > It is parameterized already with a frame and an expression.
>> > It's just that we want to hand it a different type of frame.

You are mistaken in your assertion below:

>> > You implied it wasn't parameterized with either, when it has been since 
>> > the beginning.


> Have you ever considered that you might have just been unclear?

Yes.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

This doesn't read right. Note additional line.


> On Tue, 26 Mar 2002, Andrew Cagney wrote:
> 
> 
>> > Errr, not really.
>> What I said is correct.
>> It is parameterized already with a frame and an expression.
>> It's just that we want to hand it a different type of frame.
> 
> You are mistaken in your assertion below:
> 
>> You implied it wasn't parameterized with either, when it has been since > the beginning.

If it could be interpreted that way then it wasn't the intent.

> Have you ever considered that you might have just been unclear?
> 
> Yes.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 26 Mar 2002, Andrew Cagney wrote:

> This doesn't read right. Note additional line.
> 
> 
> > On Tue, 26 Mar 2002, Andrew Cagney wrote:
> > 
> > 
> >> > Errr, not really.
> >> What I said is correct.
> >> It is parameterized already with a frame and an expression.
> >> It's just that we want to hand it a different type of frame.
> > 
> > You are mistaken in your assertion below:
> > 
> >> You implied it wasn't parameterized with either, when it has been since > the beginning.
> 
> If it could be interpreted that way then it wasn't the intent.
Then I must have misinterpreted it.
My apologies.

> 
> > Have you ever considered that you might have just been unclear?
> > 
> > Yes.
> 
> Andrew
> 
> 
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 26 Mar 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dan@dberlin.org> writes:
> > On 26 Mar 2002, Jim Blandy wrote:
> > > Actually, Daniel, I'm sorry --- I've re-read the change more
> > > carefully, and I've gotten more confused than I was before.
> > > 
> > > You've changed the Dwarf 2 location expression evaluator to consult
> > > the current register values --- not the values of the registers with
> > > respect to a specific stack frame.  I can't think of any situations in
> > > which this the correct behavior.  Can you explain more about the
> > > contexts in which this change is useful?  It seems to me that it's
> > > wrong in most of the cases I can think of.  It really needs to take a
> > > frame argument, or at the very least, read registers from the selected
> > > frame (although that's kind of gross and global-variable-ish).
> > 
> > Whoops.
> > You're right.
> > I must have merged it while on crack or something.
> > I *meant* to add the frame argument, and only require *either* the 
> > context argument (Which is what it currently takes, a CFA context)  or the 
> > frame, but it looks like I messed up.
> > 
> > What it *should* look like is closer to the one from the WIP i sent. It 
> > should call get_saved_register with the frame argument if the context is 
> > null, or get_reg with the context argument if the context is not null.
> 
> Okay --- that makes more sense.
> 
> I started reviewing the WIP, but I got interrupted.  Do you want to
> extract something from that and post it as a non-WIP patch?

I'm not sure.  Let me explain:
As it stands, the evaluator in the WIP requires a few extra arguments and 
returns a struct value, while the the one in dwarf2cfi does not.
The extra arguments are required because we need to keep track of whether 
the result is an lval or not, and whether the result is in memory or a 
register, so we can set the approriate flags on the value struct
But i'm not sure this is the right approach.

This is why the first patch was meant only to make it external, take 
either a dwarf2 cfa context, or a struct frame info, and do the right 
thing with either, in terms of handing back a location.

I didn't want to deal with the issue of whether we want to return a struct 
value, and the issue of how best to keep track of whether it's in memory 
or a register, without getting an opinion first.

So, in short, if the approach taken by the WIP evaluator is the right way 
to deal with the issue of needing to be able to set the right flags on a 
struct value, than sure, i'll take that part out, and merge it.

Otherwise, I'd rather make sure the version in the repository is 
changed the right way, merging in the other direction to the WIP.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andreas Jaeger]

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


So, since there seems to be agreement on this issue and Dan's larger
patch might need further tweaking, I'd like to get approval to commit
the appended (untested;-) patch so that this issue is closed for good.

Ok to commit to both branches?

Andreas

2002-03-27  Andreas Jaeger  <aj@suse.de>

	* dwarf2cfi.c: Give credit to Daniel Berlin, reformat copyright
	comment.

============================================================
Index: gdb/dwarf2cfi.c
--- gdb/dwarf2cfi.c	2001/12/07 12:10:15	1.1
+++ gdb/dwarf2cfi.c	2002/03/27 08:07:57
@@ -1,7 +1,7 @@
 /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
-   Copyright 2001
-   Free Software Foundation, Inc.
+   Copyright 2001, 2002 Free Software Foundation, Inc.
    Contributed by Jiri Smid, SuSE Labs.
+   Based on code written by Daniel Berlin (dan@dberlin.org).
 
    This file is part of GDB.
 

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> So, since there seems to be agreement on this issue and Dan's larger
> patch might need further tweaking, I'd like to get approval to commit
> the appended (untested;-) patch so that this issue is closed for good.
> 
> Ok to commit to both branches?
> 
> Andreas
> 
> 2002-03-27  Andreas Jaeger  <aj@suse.de>
> 
> * dwarf2cfi.c: Give credit to Daniel Berlin, reformat copyright
> 	comment.
> 
> ============================================================
> Index: gdb/dwarf2cfi.c
> --- gdb/dwarf2cfi.c	2001/12/07 12:10:15	1.1
> +++ gdb/dwarf2cfi.c	2002/03/27 08:07:57
> @@ -1,7 +1,7 @@
>  /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> -   Copyright 2001
> -   Free Software Foundation, Inc.
> +   Copyright 2001, 2002 Free Software Foundation, Inc.
>     Contributed by Jiri Smid, SuSE Labs.
> +   Based on code written by Daniel Berlin (dan@dberlin.org).
>  
>     This file is part of GDB.
>  
> 

Yes, thanks.  Can you hit the branch as well?

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andreas Jaeger]

Andrew Cagney <ac131313@cygnus.com> writes:

>> So, since there seems to be agreement on this issue and Dan's larger
>> patch might need further tweaking, I'd like to get approval to commit
>> the appended (untested;-) patch so that this issue is closed for good.
>> Ok to commit to both branches?
>> Andreas
>> 2002-03-27  Andreas Jaeger  <aj@suse.de>
>> * dwarf2cfi.c: Give credit to Daniel Berlin, reformat copyright
>> 	comment.
>> ============================================================
>> Index: gdb/dwarf2cfi.c
>> --- gdb/dwarf2cfi.c	2001/12/07 12:10:15	1.1
>> +++ gdb/dwarf2cfi.c	2002/03/27 08:07:57
>> @@ -1,7 +1,7 @@
>>  /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
>> -   Copyright 2001
>> -   Free Software Foundation, Inc.
>> +   Copyright 2001, 2002 Free Software Foundation, Inc.
>>     Contributed by Jiri Smid, SuSE Labs.
>> +   Based on code written by Daniel Berlin (dan@dberlin.org).
>>      This file is part of GDB.
>>
>
> Yes, thanks.  Can you hit the branch as well?

Yes, I've committed this to both mainline and branch,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Petr Sorfa]

Hi Jim,

> Actually, Daniel, I'm sorry --- I've re-read the change more
> carefully, and I've gotten more confused than I was before.
> 
> You've changed the Dwarf 2 location expression evaluator to consult
> the current register values --- not the values of the registers with
> respect to a specific stack frame.  I can't think of any situations in
> which this the correct behavior.  Can you explain more about the
> contexts in which this change is useful?  It seems to me that it's
> wrong in most of the cases I can think of.  It really needs to take a
> frame argument, or at the very least, read registers from the selected
> frame (although that's kind of gross and global-variable-ish).
I agree with you Jim. It needs to be frame relative.

Petr
> 
> Daniel Berlin <dan@dberlin.org> writes:
> 
> > This patch simply adds an external entry point (dwarf2_execute_stack_op),
> > that doesn't require the CFA context. It also adds code so that when the
> > context passed to execute_stack_op is NULL, we use read_register_gen to
> > get registers.
> >
> > Along the way, I made an obvious fix to DW_OP_deref_size that i'll commit
> > separately, but included in the changelog/patch because i didn't want to
> > hand edit it out.
> >
> >
> > I also added my name to the top of the file, since in reality, it's based
> > on code I sent Jiri.
> >
> > --Dan
> > 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> >
> >       * dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> >       entry point to execute_stack_op that doesn't require context.
> >       (execute_stack_op): If context is NULL, don't use get_reg, use
> >       read_register_gen.
> >         Also fix bug in DW_OP_deref_size.
> >
> >       * dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> > Index: dwarf2cfi.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dwarf2cfi.c,v
> > retrieving revision 1.1
> > diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.c
> > *** dwarf2cfi.c       2001/12/07 12:10:15     1.1
> > --- dwarf2cfi.c       2002/03/25 23:50:16
> > ***************
> > *** 1,7 ****
> >   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> > !    Copyright 2001
> >      Free Software Foundation, Inc.
> >      Contributed by Jiri Smid, SuSE Labs.
> >
> >      This file is part of GDB.
> >
> > --- 1,8 ----
> >   /* Stack unwinding code based on dwarf2 frame info for GDB, the GNU debugger.
> > !    Copyright 2001, 2002
> >      Free Software Foundation, Inc.
> >      Contributed by Jiri Smid, SuSE Labs.
> > +    Based on code written by Daniel Berlin (dan@dberlin.org)
> >
> >      This file is part of GDB.
> >
> > *************** get_reg (char *reg, struct context *cont
> > *** 840,845 ****
> > --- 841,854 ----
> >       }
> >   }
> >
> > + /* External entry point for executing dwarf2 stack operations. */
> > + CORE_ADDR
> > + dwarf2_execute_stack_op (struct objfile *objfile, char *op_ptr,
> > +                      char *op_end, CORE_ADDR initial)
> > + {
> > +   return execute_stack_op (objfile, op_ptr, op_end, NULL, initial);
> > + }
> > +
> >   /* Decode a DW_OP stack program.  Return the top of stack.  Push INITIAL
> >      onto the stack to start.  */
> >   static CORE_ADDR
> > *************** execute_stack_op (struct objfile *objfil
> > *** 963,973 ****
> > --- 972,989 ----
> >       case DW_OP_reg29:
> >       case DW_OP_reg30:
> >       case DW_OP_reg31:
> > +       if (context)
> >           get_reg ((char *) &result, context, op - DW_OP_reg0);
> > +       else
> > +         read_register_gen (op - DW_OP_reg0, (char *)&result);
> > +
> >         break;
> >       case DW_OP_regx:
> >         reg = read_uleb128 (objfile->obfd, &op_ptr);
> > +       if (context)
> >           get_reg ((char *) &result, context, reg);
> > +       else
> > +         read_register_gen (reg, (char *)&result);
> >         break;
> >
> >       case DW_OP_breg0:
> > *************** execute_stack_op (struct objfile *objfil
> > *** 1003,1015 ****
> > --- 1019,1038 ----
> >       case DW_OP_breg30:
> >       case DW_OP_breg31:
> >         offset = read_sleb128 (objfile->obfd, &op_ptr);
> > +       if (context)
> >           get_reg ((char *) &result, context, op - DW_OP_breg0);
> > +       else
> > +         read_register_gen (op - DW_OP_breg0, (char *)&result);
> > +
> >         result += offset;
> >         break;
> >       case DW_OP_bregx:
> >         reg = read_uleb128 (objfile->obfd, &op_ptr);
> >         offset = read_sleb128 (objfile->obfd, &op_ptr);
> > +       if (context)
> >           get_reg ((char *) &result, context, reg);
> > +       else
> > +         read_register_gen (reg, (char *)&result);
> >         result += offset;
> >         break;
> >
> > *************** execute_stack_op (struct objfile *objfil
> > *** 1067,1080 ****
> >           {
> >           case DW_OP_deref:
> >             {
> > !             char *ptr = (char *) result;
> >               result = read_pointer (objfile->obfd, &ptr);
> >             }
> >             break;
> >
> >           case DW_OP_deref_size:
> >             {
> > !             char *ptr = (char *) result;
> >               switch (*op_ptr++)
> >                 {
> >                 case 1:
> > --- 1090,1103 ----
> >           {
> >           case DW_OP_deref:
> >             {
> > !             char *ptr = (char *) &result;
> >               result = read_pointer (objfile->obfd, &ptr);
> >             }
> >             break;
> >
> >           case DW_OP_deref_size:
> >             {
> > !             char *ptr = (char *) &result;
> >               switch (*op_ptr++)
> >                 {
> >                 case 1:
> > Index: dwarf2cfi.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dwarf2cfi.h,v
> > retrieving revision 1.1
> > diff -c -3 -p -w -B -b -r1.1 dwarf2cfi.h
> > *** dwarf2cfi.h       2001/12/07 12:10:15     1.1
> > --- dwarf2cfi.h       2002/03/25 23:50:16
> > *************** void cfi_get_saved_register (char *raw_b
> > *** 63,66 ****
> > --- 63,72 ----
> >   void cfi_virtual_frame_pointer (CORE_ADDR pc, int *frame_regnum,
> >                               LONGEST * frame_offset);
> >
> > + /*  Execute a set of DWARF2 stack operations, starting with INITIAL
> > +     as the address on the stack. */
> > + CORE_ADDR dwarf2_execute_stack_op (struct objfile *objfile,
> > +                                char *op_ptr, char *op_end,
> > +                                CORE_ADDR initial);
> > +
> >   #endif
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/ChangeLog,v
> > retrieving revision 1.2349
> > diff -c -3 -p -w -B -b -r1.2349 ChangeLog
> > *** ChangeLog 2002/03/25 19:47:39     1.2349
> > --- ChangeLog 2002/03/25 23:50:17
> > ***************
> > *** 1,3 ****
> > --- 1,12 ----
> > + 2002-03-25  Daniel Berlin  <dan@dberlin.org>
> > +
> > +     * dwarf2cfi.c (dwarf2_execute_stack_op): New function, external
> > +     entry point to execute_stack_op that doesn't require context.
> > +     (execute_stack_op): If context is NULL, don't use get_reg, use
> > +     read_register_gen.
> > +
> > +     * dwarf2cfi.h (dwarf2_execute_stack_op): New prototype.
> > +
> >   2002-03-25  Jeff Law (law@redhat.com)
> >
> >       * linux-proc.c (read_mapping): Scan up to end of line for filename.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

> I agree with you Jim. It needs to be frame relative.
Of course, nobody disagrees.
If you look at the archives of gdb-patches, you'll see i've written this 
code multiple times now, in different ways, and every time, have made it 
frame relative.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Richard Stallman]

I am glad you were able to resolve the problem without my help.
Thanks.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

Daniel Berlin <dan@dberlin.org> writes:
> I didn't want to deal with the issue of whether we want to return a struct 
> value, and the issue of how best to keep track of whether it's in memory 
> or a register, without getting an opinion first.

I spoke with Andrew on the phone yesterday, and he and I have
different ideas about how things should go.  I don't think I
understood the path of changes he wanted to see.

My personal inclination is to make the Dwarf 2 location expression
interpreter as independent from GDB as possible.  It can use the
CORE_ADDR type for stack elements, but it should take arguments
specifying:
- the expression as a simple char * pointer and length,
- the architecture's address size,
- function pointers for reading memory and registers that simply hand
  back a CORE_ADDR value (thus keeping the interpreter innocent of
  endianness issues), and
- the frame base address (for DW_OP_fbreg)

It should return a structure that says whether the location expression
specified a particular register (i.e., DW_OP_reg0 and friends) or an
address.  Actually, the return value should be a list of pieces, each
of which gives a byte length and then a register or address.

But I tend to think it shouldn't take a struct frame_info or struct
context, and it shouldn't return a struct value.  Sure, you'll need
more glue code than you would if it took just the right arguments for
the use we have in mind, but keeping it as innocent of GDB as possible
makes the interface easier to understand: you don't need to wonder how
it interacts with a frame's saved registers, how it finds the frame
base, and so on.  You can look at the code and say, "Ah, this doesn't
worry about any of that."  There's a simple test for the module
boundaries: if a behavior is described in the Dwarf spec chapter on
location expressions, it should be inside; otherwise, it should be
outside.  And once you've written frame/struct value glue code,
everyone can use that and nobody minds.

What a lot of hand-waving.  Sorry.  Hopefully you'll see what I'm
getting at.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 28 Mar 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dan@dberlin.org> writes:
> > I didn't want to deal with the issue of whether we want to return a struct 
> > value, and the issue of how best to keep track of whether it's in memory 
> > or a register, without getting an opinion first.
> 
> I spoke with Andrew on the phone yesterday, and he and I have
> different ideas about how things should go.  I don't think I
> understood the path of changes he wanted to see.
> 
> My personal inclination is to make the Dwarf 2 location expression
> interpreter as independent from GDB as possible.  It can use the
> CORE_ADDR type for stack elements, but it should take arguments
> specifying:
> - the expression as a simple char * pointer and length,
Done

> - the architecture's address size,

This is already available as a global, no?
> - function pointers for reading memory and registers that simply hand
>   back a CORE_ADDR value (thus keeping the interpreter innocent of
>   endianness issues), and

It uses functions that deal with the endianness issues for us, and are 
used elsewhere in GDB.

Remember, I test on both x86, and powerpc.
:)

> - the frame base address (for DW_OP_fbreg)

Not possible.
the frame base can be a location list.
That's why it pulls it out of the frame function on the fly. 

> 
> It should return a structure that says whether the location expression
> specified a particular register (i.e., DW_OP_reg0 and friends) or an
> address. 

This is a struct value *, in effect, which is what i'm using.

> Actually, the return value should be a list of pieces, each
> of which gives a byte length and then a register or address.

struct value needs to be modified to allow pieces anyway, so i was going 
to add the "list of pieces there", and just set the right flags.

> 
> But I tend to think it shouldn't take a struct frame_info or struct
> context, and it shouldn't return a struct value. 

It needs the context. In the case of unwinding, we need the unwinding 
context.

In order to recursively evaluate things like the fbreg, we also need the 
frame we are currently evaluating in anyway.

Lastly, as the dwarf3 doc says, "In the case of locations used for 
structure members, the computation implicitly pushes the base 
address of the immediately containing structure on the stack before 
evaluation of the addressing operation".
So we need an initial value parameter.

For pointer to members, the docs says
"

For an expression such as
object.*mbr_ptr
where mbr_ptr has some pointer to member type, a debugger should:
1. Push the value of mbr_ptr onto the location expression stack.
2. Push the base address of object onto the location expression stack.
3. Evaluate the DW_AT_use_location expression given in the type of 
mbr_ptr.
"

struct value is exact the 
abstraction you mention above, that specifies where something is.

>  Sure, you'll need
> more glue code than you would if it took just the right arguments for
> the use we have in mind, but keeping it as innocent of GDB as possible
> makes the interface easier to understand: you don't need to wonder how
> it interacts with a frame's saved registers, how it finds the frame
> base, and so on.  You can look at the code and say, "Ah, this doesn't
> worry about any of that."
The problem is it needs to.
>   There's a simple test for the module
> boundaries: if a behavior is described in the Dwarf spec chapter on
> location expressions, it should be inside; otherwise, it should be
> outside.  And once you've written frame/struct value glue code,
> everyone can use that and nobody minds.

I think you need to look a bit closer at that document.
:)
They changed location expressions to be a special case of "dwarf 
expressions".
Implicit in the definition of location expression is now that it has some 
context. In fact, the stack machine assumes such a context.

Nowhere does it actually mention how to evaluate the operations, just what 
they do.
It just assumes you can magically get and evaluate things.

> 
> What a lot of hand-waving.  Sorry.  Hopefully you'll see what I'm
> getting at.
> 
Sure, i'm just not sure it's possible.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> 
> I spoke with Andrew on the phone yesterday, and he and I have
> different ideas about how things should go.  I don't think I
> understood the path of changes he wanted to see.

(Tuesday .CA) The bulk of the discussion was about:
http://sources.redhat.com/ml/gdb/2002-03/msg00154.html
and its implications.

However, implementation details on the bit of code below did come up. 
 From memory JimB was proposing that the code be in two parts: a 
completly separate 100% parameterized engine; a wrapper function s(one 
for CFI one for Dan's needs).  I was more for a single function and a 
``struct frame_info *'' parameter.  Given I'm not likely to be the one 
implementing it, it probably doesn't matter to me :-)

> My personal inclination is to make the Dwarf 2 location expression
> interpreter as independent from GDB as possible.  It can use the
> CORE_ADDR type for stack elements, but it should take arguments
> specifying:
> - the expression as a simple char * pointer and length,
> - the architecture's address size,
> - function pointers for reading memory and registers that simply hand
>   back a CORE_ADDR value (thus keeping the interpreter innocent of
>   endianness issues), and
> - the frame base address (for DW_OP_fbreg)

I suspect a function call here might be a good idea as well - to ensure 
that the value isn't used when it hasn't been computed or to delay its 
computation.

Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

I've read through the new Dwarf spec some more.  You're right ---
they've added a bunch of stuff like DW_OP_push_object_address and
DW_OP_call, and cases where you're supposed to push stuff on the
stack, etc.

But what I'm going for here is something we could, in the long run,
put in libiberty and just have GDB use from there.  Surely there are
other applications that could use a Dwarf expression interpreter.

Would something like the below be sufficient?  Rename to taste.  (Feel
free to say, "Yes, but that's way beyond what I offered to do."  Also
feel free to say, "You look like you're trying to write C++ programs
in C.")


struct dwarf_expr_context
{
  /* The stack of values, allocated with xmalloc.  */
  ADDR_TYPE *stack;

  /* The number of values currently pushed on the stack, and the
     number of elements allocated to the stack.  */
  int stack_len, stack_allocated;

  /* The size of an address, in bits.  */
  int addr_size;

  /* Return the value of register number REGNUM.  */
  ADDR_TYPE (*read_reg) (void *baton, int regnum);
  void *read_reg_baton;

  /* Return the LEN-byte value at ADDR.  */
  ADDR_TYPE (*read_mem) (void *baton, ADDR_TYPE addr, size_t len);
  void *read_mem_baton;

  /* Return the location expression for the frame base attribute.  The
     result must be live until the current expression evaluation is
     complete.  */
  unsigned char *(*get_frame_base) (void *baton);
  void *get_frame_base_baton;

  /* Return the location expression for the dwarf expression
     subroutine in the die at OFFSET in the current compilation unit.
     The result must be live until the current expression evaluation
     is complete.  */
  unsigned char *(*get_subr) (void *baton, offset_t offset);
  void *get_subr_baton;

  /* Return the `object address' for DW_OP_push_object_address.  */
  ADDR_TYPE (*get_object_address) (void *baton);
  void *get_object_address_baton;

  /* The current depth of dwarf expression recursion, via DW_OP_call*,
     DW_OP_fbreg, DW_OP_push_object_address, etc., and the maximum
     depth we'll tolerate before raising an error.  */
  int recursion_depth, max_recursion_depth;

  /* Add whatever you want here; the caller is supposed to use
     new_dwarf_expr_context to make these, which can fill in default
     values.  */
};


/* Return a new context, with no values on the stack.  */ 
struct dwarf_expr_context *new_dwarf_expr_context ();

/* Free CONTEXT.  */
void free_dwarf_expr_context (struct dwarf_expr_context *context);

/* Push VALUE on CONTEXT's stack.  Reallocate the stack as needed.  */
void dwarf_expr_push (struct dwarf_expr_context *context, ADDR_TYPE value);

/* Evaluate the LEN bytes at ADDR as a dwarf expression in CONTEXT.  */
void dwarf_expr_eval (struct dwarf_expr_context *context,
                      unsigned char *addr, size_t len);

/* Return the value N values down from the top of CONTEXT's stack.
   This raises an error if there aren't at least N+1 values on the stack.  */
ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 28 Mar 2002, Jim Blandy wrote:

> 
> I've read through the new Dwarf spec some more.  You're right ---
> they've added a bunch of stuff like DW_OP_push_object_address and
> DW_OP_call, and cases where you're supposed to push stuff on the
> stack, etc.
> 
> But what I'm going for here is something we could, in the long run,
> put in libiberty and just have GDB use from there.  Surely there are
> other applications that could use a Dwarf expression interpreter.

I'm not so sure about this, that's the reason I think you might be 
overengineering it.
1. I doubt DJ would put it in libiberty, it's just not generally useful 
enough.
2. There aren't *that* many things that need support for dwarf 
expressions. Those that do, either already have it, or it's not a 
significant amount of work to make an evaluator.
> 
> Would something like the below be sufficient? 
Sure, but some of it is way overkill.
In particular, you just need some initial value, or no initial value, not 
a push object address value/other types of things that may get pushed to 
the front.
Also, why would something need our evaluator if they already knew how to 
read DIE's at a given offset? It's very likely they can also evaluate 
expressions if they can read DWARF2 at all.

If this evaluator was part of a "libdwarf" type thing, I'd think it was a 
good idea to do the below, but I'm just not sure of general utility.

If, however, this is what GDB people want it to look like, i'll happily 
implement it.  It's not like it'll be that much more work for me.

> free to say, "Yes, but that's way beyond what I offered to do."  Also
> feel free to say, "You look like you're trying to write C++ programs
> in C.")
> 
> 
> struct dwarf_expr_context
> {
>   /* The stack of values, allocated with xmalloc.  */
>   ADDR_TYPE *stack;
> 
>   /* The number of values currently pushed on the stack, and the
>      number of elements allocated to the stack.  */
>   int stack_len, stack_allocated;
> 
>   /* The size of an address, in bits.  */
>   int addr_size;
> 
>   /* Return the value of register number REGNUM.  */
>   ADDR_TYPE (*read_reg) (void *baton, int regnum);
>   void *read_reg_baton;
> 
>   /* Return the LEN-byte value at ADDR.  */
>   ADDR_TYPE (*read_mem) (void *baton, ADDR_TYPE addr, size_t len);
>   void *read_mem_baton;
> 
>   /* Return the location expression for the frame base attribute.  The
>      result must be live until the current expression evaluation is
>      complete.  */
>   unsigned char *(*get_frame_base) (void *baton);
>   void *get_frame_base_baton;
> 
>   /* Return the location expression for the dwarf expression
>      subroutine in the die at OFFSET in the current compilation unit.
>      The result must be live until the current expression evaluation
>      is complete.  */
>   unsigned char *(*get_subr) (void *baton, offset_t offset);
>   void *get_subr_baton;
> 
>   /* Return the `object address' for DW_OP_push_object_address.  */
>   ADDR_TYPE (*get_object_address) (void *baton);
>   void *get_object_address_baton;
> 
>   /* The current depth of dwarf expression recursion, via DW_OP_call*,
>      DW_OP_fbreg, DW_OP_push_object_address, etc., and the maximum
>      depth we'll tolerate before raising an error.  */
>   int recursion_depth, max_recursion_depth;
> 
>   /* Add whatever you want here; the caller is supposed to use
>      new_dwarf_expr_context to make these, which can fill in default
>      values.  */
> };
> 
> 
> /* Return a new context, with no values on the stack.  */ 
> struct dwarf_expr_context *new_dwarf_expr_context ();
> 
> /* Free CONTEXT.  */
> void free_dwarf_expr_context (struct dwarf_expr_context *context);
> 
> /* Push VALUE on CONTEXT's stack.  Reallocate the stack as needed.  */
> void dwarf_expr_push (struct dwarf_expr_context *context, ADDR_TYPE value);
> 
> /* Evaluate the LEN bytes at ADDR as a dwarf expression in CONTEXT.  */
> void dwarf_expr_eval (struct dwarf_expr_context *context,
>                       unsigned char *addr, size_t len);
> 
> /* Return the value N values down from the top of CONTEXT's stack.
>    This raises an error if there aren't at least N+1 values on the stack.  */
> ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);
> 

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

It may well be overengineered.  A libdwarf is indeed what I had in
mind; I thought it might be nice to start putting together the pieces
for it.

Daniel Berlin <dan@dberlin.org> writes:
> In particular, you just need some initial value, or no initial value, not 
> a push object address value/other types of things that may get pushed to 
> the front.

Well, DW_AT_data_member_location expressions want the base address of
the innermost enclosing structure on the stack, whereas
DW_AT_use_location expressions want the pointer-to-member value and
the object's base address on the stack.  So we've got situations which
need zero, one, and two values on the stack.  So it seems like the
basic interface should let people push as much as they want.

> Also, why would something need our evaluator if they already knew how to 
> read DIE's at a given offset? It's very likely they can also evaluate 
> expressions if they can read DWARF2 at all.

Well, to share code, I guess.  They'd toss their interpreter to use
ours, and spread the maintenance job around.  I have no clients in
mind, just general principle.  When we've got something whose behavior
is well-specified with no reference to GDB, it just seems like good
practice to produce an implementation that, likewise, is independent
of GDB.

> If, however, this is what GDB people want it to look like, i'll happily 
> implement it.  It's not like it'll be that much more work for me.

I'd approve it.  :)

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Petr Sorfa]

Hi Jim,

I've implemented a dwarf3 location expression parser for GDB. My
solution is, well, different than yours. I've gone for a more simpler
(limited) solution based on the existing dwarf2read.c decode_locdesc
function. It basically processes the location expression data passed to
through a "dwarf block" which contains the raw DWARF data block and it's
size.

Since GDB currently does not have an intermediate location expression
framework, I attach the dwarf blocks to relevant areas, such as:

struct general_symbol_info (for data location)
struct type (for array ranges (upper and lower bounds, stride),
associated and allocated expressions)

I understand that you are suggesting a more useful and generic solution
which can be detached from gdb completely.

Just letting you know the approach I took.

Petr

> I've read through the new Dwarf spec some more.  You're right ---
> they've added a bunch of stuff like DW_OP_push_object_address and
> DW_OP_call, and cases where you're supposed to push stuff on the
> stack, etc.
> 
> But what I'm going for here is something we could, in the long run,
> put in libiberty and just have GDB use from there.  Surely there are
> other applications that could use a Dwarf expression interpreter.
> 
> Would something like the below be sufficient?  Rename to taste.  (Feel
> free to say, "Yes, but that's way beyond what I offered to do."  Also
> feel free to say, "You look like you're trying to write C++ programs
> in C.")
> 
> struct dwarf_expr_context
> {
>   /* The stack of values, allocated with xmalloc.  */
>   ADDR_TYPE *stack;
> 
>   /* The number of values currently pushed on the stack, and the
>      number of elements allocated to the stack.  */
>   int stack_len, stack_allocated;
> 
>   /* The size of an address, in bits.  */
>   int addr_size;
> 
>   /* Return the value of register number REGNUM.  */
>   ADDR_TYPE (*read_reg) (void *baton, int regnum);
>   void *read_reg_baton;
> 
>   /* Return the LEN-byte value at ADDR.  */
>   ADDR_TYPE (*read_mem) (void *baton, ADDR_TYPE addr, size_t len);
>   void *read_mem_baton;
> 
>   /* Return the location expression for the frame base attribute.  The
>      result must be live until the current expression evaluation is
>      complete.  */
>   unsigned char *(*get_frame_base) (void *baton);
>   void *get_frame_base_baton;
> 
>   /* Return the location expression for the dwarf expression
>      subroutine in the die at OFFSET in the current compilation unit.
>      The result must be live until the current expression evaluation
>      is complete.  */
>   unsigned char *(*get_subr) (void *baton, offset_t offset);
>   void *get_subr_baton;
> 
>   /* Return the `object address' for DW_OP_push_object_address.  */
>   ADDR_TYPE (*get_object_address) (void *baton);
>   void *get_object_address_baton;
> 
>   /* The current depth of dwarf expression recursion, via DW_OP_call*,
>      DW_OP_fbreg, DW_OP_push_object_address, etc., and the maximum
>      depth we'll tolerate before raising an error.  */
>   int recursion_depth, max_recursion_depth;
> 
>   /* Add whatever you want here; the caller is supposed to use
>      new_dwarf_expr_context to make these, which can fill in default
>      values.  */
> };
> 
> /* Return a new context, with no values on the stack.  */
> struct dwarf_expr_context *new_dwarf_expr_context ();
> 
> /* Free CONTEXT.  */
> void free_dwarf_expr_context (struct dwarf_expr_context *context);
> 
> /* Push VALUE on CONTEXT's stack.  Reallocate the stack as needed.  */
> void dwarf_expr_push (struct dwarf_expr_context *context, ADDR_TYPE value);
> 
> /* Evaluate the LEN bytes at ADDR as a dwarf expression in CONTEXT.  */
> void dwarf_expr_eval (struct dwarf_expr_context *context,
>                       unsigned char *addr, size_t len);
> 
> /* Return the value N values down from the top of CONTEXT's stack.
>    This raises an error if there aren't at least N+1 values on the stack.  */
> ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 2 Apr 2002, Petr Sorfa wrote:

> Hi Jim,
> 
> I've implemented a dwarf3 location expression parser for GDB. My
> solution is, well, different than yours. I've gone for a more simpler
> (limited) solution based on the existing dwarf2read.c decode_locdesc
> function. It basically processes the location expression data passed to
> through a "dwarf block" which contains the raw DWARF data block and it's
> size.

I'm curious why you reimplemented this approach.
If you look back to last year, you'll note I sent something that does 
exactly this, to gdb-patches.
I never got around to attach dwarf blocks to types, because Andrew wanted 
it more independent of DWARF2.
You probably could have saved a lot of time in writing his stuff, which is 
why i'm curious.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 1 Apr 2002, Jim Blandy wrote:

> 
> It may well be overengineered.  A libdwarf is indeed what I had in
> mind; I thought it might be nice to start putting together the pieces
> for it.

1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
that, if you wanted a dwarf reader (in fact, this is what the majority of 
consumers do use).
It would make more sense to just implement what's missing (it contains no 
macro info reading, and no generic location expression support).
2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
works pretty well. 


> 
> Daniel Berlin <dan@dberlin.org> writes:
> > In particular, you just need some initial value, or no initial value, not 
> > a push object address value/other types of things that may get pushed to 
> > the front.
> 
> Well, DW_AT_data_member_location expressions want the base address of
> the innermost enclosing structure on the stack, whereas
> DW_AT_use_location expressions want the pointer-to-member value and
> the object's base address on the stack.  So we've got situations which
> need zero, one, and two values on the stack.  So it seems like the
> basic interface should let people push as much as they want.
> 
> > Also, why would something need our evaluator if they already knew how to 
> > read DIE's at a given offset? It's very likely they can also evaluate 
> > expressions if they can read DWARF2 at all.
> 
> Well, to share code, I guess.  They'd toss their interpreter to use
> ours, and spread the maintenance job around. 
I sincerely doubt they would do this.
They gain nothing by conversion, but become dependent on us.
:)


> I have no clients in
> mind, just general principle.  When we've got something whose behavior
> is well-specified with no reference to GDB, it just seems like good
> practice to produce an implementation that, likewise, is independent
> of GDB.
> 
> > If, however, this is what GDB people want it to look like, i'll happily 
> > implement it.  It's not like it'll be that much more work for me.
> 
> I'd approve it.  :)
> 


I'll do it, i'm just concerned we are thinking of duplicating a library 
for the sake of duplicating a library.
:)
--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside ofCFI

[Petr Sorfa]

Hi Dan,

> > I've implemented a dwarf3 location expression parser for GDB. My
> > solution is, well, different than yours. I've gone for a more simpler
> > (limited) solution based on the existing dwarf2read.c decode_locdesc
> > function. It basically processes the location expression data passed to
> > through a "dwarf block" which contains the raw DWARF data block and it's
> > size.
> 
> I'm curious why you reimplemented this approach.
> If you look back to last year, you'll note I sent something that does
> exactly this, to gdb-patches.
> I never got around to attach dwarf blocks to types, because Andrew wanted
> it more independent of DWARF2.
> You probably could have saved a lot of time in writing his stuff, which is
> why i'm curious.
As far as I recall your patch did not support Dwarf3 DW_OPs which
were/are my more immediate concern. The main reason I did implement it
was to get it done as quickly as possible. At the time we were still
debating on the proper solution (before deciding on the independent
approach - I am aware that a patch was made available supporting some of
this last year.) Basically it is/was a proof of concept. It works. I
also got the impression that other folks were working on the
intermediate solution. If this is not the case I will gladly help
implement relevant bits.

Petr

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

Daniel Berlin <dan@dberlin.org> writes:
> > It may well be overengineered.  A libdwarf is indeed what I had in
> > mind; I thought it might be nice to start putting together the pieces
> > for it.
> 
> 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> that, if you wanted a dwarf reader (in fact, this is what the majority of 
> consumers do use).
> It would make more sense to just implement what's missing (it contains no 
> macro info reading, and no generic location expression support).
> 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> works pretty well. 

Does Uli's libdwarf have an expression evaluator?

> I'll do it, i'm just concerned we are thinking of duplicating a library 
> for the sake of duplicating a library.
> :)

I didn't know about the existing libdwarf, or Uli's.  It would be nice
to start using those, if we can.  And I'll bet if the interfaces are
troublesome for GDB, then Uli would be happy to change it.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz]

On Tue, Apr 02, 2002 at 02:28:12PM -0500, Jim Blandy wrote:
> 
> Daniel Berlin <dan@dberlin.org> writes:
> > > It may well be overengineered.  A libdwarf is indeed what I had in
> > > mind; I thought it might be nice to start putting together the pieces
> > > for it.
> > 
> > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> > that, if you wanted a dwarf reader (in fact, this is what the majority of 
> > consumers do use).
> > It would make more sense to just implement what's missing (it contains no 
> > macro info reading, and no generic location expression support).
> > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> > works pretty well. 
> 
> Does Uli's libdwarf have an expression evaluator?
> 
> > I'll do it, i'm just concerned we are thinking of duplicating a library 
> > for the sake of duplicating a library.
> > :)
> 
> I didn't know about the existing libdwarf, or Uli's.  It would be nice
> to start using those, if we can.  And I'll bet if the interfaces are
> troublesome for GDB, then Uli would be happy to change it.

I didn't know that the existing libdwarf had been LGPL'd; the copy on
SGI's site certainly hasn't been, but that's a bit old.  However, it's
exceedingly unlikely we could get the copyright assigned to the FSF.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:

> On Tue, Apr 02, 2002 at 02:28:12PM -0500, Jim Blandy wrote:
> > 
> > Daniel Berlin <dan@dberlin.org> writes:
> > > > It may well be overengineered.  A libdwarf is indeed what I had in
> > > > mind; I thought it might be nice to start putting together the pieces
> > > > for it.
> > > 
> > > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> > > that, if you wanted a dwarf reader (in fact, this is what the majority of 
> > > consumers do use).
> > > It would make more sense to just implement what's missing (it contains no 
> > > macro info reading, and no generic location expression support).
> > > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> > > works pretty well. 
> > 
> > Does Uli's libdwarf have an expression evaluator?
> > 
> > > I'll do it, i'm just concerned we are thinking of duplicating a library 
> > > for the sake of duplicating a library.
> > > :)
> > 
> > I didn't know about the existing libdwarf, or Uli's.  It would be nice
> > to start using those, if we can.  And I'll bet if the interfaces are
> > troublesome for GDB, then Uli would be happy to change it.
> 
> I didn't know that the existing libdwarf had been LGPL'd; the copy on
> SGI's site certainly hasn't been, but that's a bit old. 
Very old, actually.
ftp://ftp.sgi.com/sgi/dev/davea/libdwarf2001May23.tar.gz is the latest 
around.

>  However, it's
> exceedingly unlikely we could get the copyright assigned to the FSF.
So?

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 2 Apr 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dan@dberlin.org> writes:
> > > It may well be overengineered.  A libdwarf is indeed what I had in
> > > mind; I thought it might be nice to start putting together the pieces
> > > for it.
> > 
> > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> > that, if you wanted a dwarf reader (in fact, this is what the majority of 
> > consumers do use).
> > It would make more sense to just implement what's missing (it contains no 
> > macro info reading, and no generic location expression support).
> > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> > works pretty well. 
> 
> Does Uli's libdwarf have an expression evaluator?
Nope.
It is part of a rewrite of ld he was working on.

> 
> > I'll do it, i'm just concerned we are thinking of duplicating a library 
> > for the sake of duplicating a library.
> > :)
> 
> I didn't know about the existing libdwarf, or Uli's.  It would be nice
> to start using those, if we can.  And I'll bet if the interfaces are
> troublesome for GDB, then Uli would be happy to change it.
I hope he doesn't change them, as they match libdwarf. libdwarf's 
interfaces are much easier to deal with than gdb's.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz]

On Tue, Apr 02, 2002 at 02:46:39PM -0500, Daniel Berlin wrote:
> On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:
> >  However, it's
> > exceedingly unlikely we could get the copyright assigned to the FSF.
> So?

So it would be a royal pain in the ass to distribute with GDB and
include as part of GDB.  The FSF "doesn't like it when we do that".
That's existing policy, like it or not.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:

> On Tue, Apr 02, 2002 at 02:46:39PM -0500, Daniel Berlin wrote:
> > On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:
> > >  However, it's
> > > exceedingly unlikely we could get the copyright assigned to the FSF.
> > So?
> 
> So it would be a royal pain in the ass to distribute with GDB and
> include as part of GDB.  The FSF "doesn't like it when we do that".
> That's existing policy, like it or not.

Well, let's ask dave anderson if he's willing to assign copyright, since 
AFAIK, he's the sole author of libdwarf.
--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz]

On Tue, Apr 02, 2002 at 04:12:26PM -0500, Daniel Berlin wrote:
> On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:
> 
> > On Tue, Apr 02, 2002 at 02:46:39PM -0500, Daniel Berlin wrote:
> > > On Tue, 2 Apr 2002, Daniel Jacobowitz wrote:
> > > >  However, it's
> > > > exceedingly unlikely we could get the copyright assigned to the FSF.
> > > So?
> > 
> > So it would be a royal pain in the ass to distribute with GDB and
> > include as part of GDB.  The FSF "doesn't like it when we do that".
> > That's existing policy, like it or not.
> 
> Well, let's ask dave anderson if he's willing to assign copyright, since 
> AFAIK, he's the sole author of libdwarf.
> --Dan

Well, he'd probably have to do hoops through SGI; but still, it's
definitely worth asking!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 2 Apr 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dan@dberlin.org> writes:
> > > It may well be overengineered.  A libdwarf is indeed what I had in
> > > mind; I thought it might be nice to start putting together the pieces
> > > for it.
> > 
> > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> > that, if you wanted a dwarf reader (in fact, this is what the majority of 
> > consumers do use).
> > It would make more sense to just implement what's missing (it contains no 
> > macro info reading, and no generic location expression support).
> > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> > works pretty well. 
> 
> Does Uli's libdwarf have an expression evaluator?
> 
> > I'll do it, i'm just concerned we are thinking of duplicating a library 
> > for the sake of duplicating a library.
> > :)
> 
> I didn't know about the existing libdwarf, or Uli's.  It would be nice
> to start using those, if we can.  And I'll bet if the interfaces are
> troublesome for GDB, then Uli would be happy to change it.


I'll tell you what.
Since I don't have Uli's handy anymore, and I know the interface was 
exactly that of libdwarf's, i'm willing to write a GPL'd library with the 
same interface.
It likely won't take more than a weekend to give you enough to replace 
what the dwarf2 reader currently does.

I won't change the interface, however. The libdwarf interface is sensible, 
and easy to use.  The main reason i won't change it, though, is that it 
hides all the things that we take for granted or do wrong in the current 
dwarf2 reader, and thus, causes most of the pain of modifying it.

Specifically, no internal access to any structure is allowed, you just 
pass around opaque contexts.  No globals, either.

Of course, the hilarious part of all this work is that Intel did it once 
already, including writing what appears to be their own compatible 
libdwarf (At least, I don't have much older versions of libdwarf, but the 
copyrights aren't in the intel version, but all the interfaces are the 
same. It also supports some things libdwarf still doesn't, which makes me 
think it was done separately), and rewriting dwarf2read.c to use it.

3 years ago, by the timestamps (they are all timestamp'd at March 8, 
1999).

Hilarious in that it makes me want to cry, of course.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz]

On Tue, Apr 02, 2002 at 09:55:06PM -0500, Daniel Berlin wrote:
> On 2 Apr 2002, Jim Blandy wrote:
> 
> > 
> > Daniel Berlin <dan@dberlin.org> writes:
> > > > It may well be overengineered.  A libdwarf is indeed what I had in
> > > > mind; I thought it might be nice to start putting together the pieces
> > > > for it.
> > > 
> > > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use 
> > > that, if you wanted a dwarf reader (in fact, this is what the majority of 
> > > consumers do use).
> > > It would make more sense to just implement what's missing (it contains no 
> > > macro info reading, and no generic location expression support).
> > > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that 
> > > works pretty well. 
> > 
> > Does Uli's libdwarf have an expression evaluator?
> > 
> > > I'll do it, i'm just concerned we are thinking of duplicating a library 
> > > for the sake of duplicating a library.
> > > :)
> > 
> > I didn't know about the existing libdwarf, or Uli's.  It would be nice
> > to start using those, if we can.  And I'll bet if the interfaces are
> > troublesome for GDB, then Uli would be happy to change it.
> 
> 
> I'll tell you what.
> Since I don't have Uli's handy anymore, and I know the interface was 
> exactly that of libdwarf's, i'm willing to write a GPL'd library with the 
> same interface.
> It likely won't take more than a weekend to give you enough to replace 
> what the dwarf2 reader currently does.

That'd be cool.

> I won't change the interface, however. The libdwarf interface is sensible, 
> and easy to use.  The main reason i won't change it, though, is that it 
> hides all the things that we take for granted or do wrong in the current 
> dwarf2 reader, and thus, causes most of the pain of modifying it.
> 
> Specifically, no internal access to any structure is allowed, you just 
> pass around opaque contexts.  No globals, either.

The concept's OK.  There's some places where I think we'll need a
little more; for instance, a hook to provide the contents of Dwarf
sections instead of it reading them from the file.  (Why, you ask? 
Because sometimes we need to apply relocations to them.  I really doubt
that's in the scope of a DWARF-2 reader.) I suppose for the convenience
of having a good DWARF-2 reader, I can move the bad-compiler
line-number-fixup stuff outside of the reader; that shouldn't be too
hard to do, and would be much cleaner.  Those are the only two major
hacks I can think of at the moment that would really be beyond scope of
the reader.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Stan Shebs]

Daniel Berlin wrote:
> 
> [...]
> 
> Of course, the hilarious part of all this work is that Intel did it once
> already, including writing what appears to be their own compatible
> libdwarf (At least, I don't have much older versions of libdwarf, but the
> copyrights aren't in the intel version, but all the interfaces are the
> same. It also supports some things libdwarf still doesn't, which makes me
> think it was done separately), and rewriting dwarf2read.c to use it.
> 
> 3 years ago, by the timestamps (they are all timestamp'd at March 8,
> 1999).

It's older than that - I was trying to get them to donate it to
the FSF back around 1996 or so, when the i960 folks made a big
switch over to ELF/DWARF.  Alas, they wanted to retain control of
it or some such, which in the long run didn't do them a bit of good,
of course.

Stan

PS I wonder if corporations would be more willing to donate these
things if they got a tax break for them...

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

To get back to the issue at hand:

Daniel B., if you can tweak the Dwarf expression evaluator into a form
that Uli is willing to incorporate into his libdwarf, then that's a
pretty good test of its indpendence from GDB's internals, in my view.

Actually changing GDB to use (anybody's) libdwarf is a whole separate
project --- it could be worth pursuing, but it's not our (or at least
my) top priority.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On Wed, 2002-04-03 at 16:05, Jim Blandy wrote:
> 
> To get back to the issue at hand:
> 
> Daniel B., if you can tweak the Dwarf expression evaluator into a form
> that Uli is willing to incorporate into his libdwarf, then that's a
> pretty good test of its indpendence from GDB's internals, in my view.

Let me ping him and see if he's still actually working on this stuff.
In the meanwhile, i'll modify it to the structure you had posted
earlier.

> 
> Actually changing GDB to use (anybody's) libdwarf is a whole separate
> project --- it could be worth pursuing, but it's not our (or at least
> my) top priority.

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Andrew Cagney]

> On 28 Mar 2002, Jim Blandy wrote:
> 
> 
>> 
>> I've read through the new Dwarf spec some more.  You're right ---
>> they've added a bunch of stuff like DW_OP_push_object_address and
>> DW_OP_call, and cases where you're supposed to push stuff on the
>> stack, etc.
>> 
>> But what I'm going for here is something we could, in the long run,
>> put in libiberty and just have GDB use from there.  Surely there are
>> other applications that could use a Dwarf expression interpreter.
> 
> 
> I'm not so sure about this, that's the reason I think you might be 
> overengineering it.

Yes, I'd tend to agree.

enjoy,
Andrew

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

So i'm implementing this, and want to know
...
> /* Return the value N values down from the top of CONTEXT's stack.
>    This raises an error if there aren't at least N+1 values on the stack.  */
> ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);
> 

How would you like me to raise the error?
Should i add an error handling function to the dwarf_expr_context struct? 
Or just call "error", under the assumption that any libdwarf library we 
write would have error functions of it's own (all the libdwarf's do), and 
that it'll be the typical printf arguments error function.

--Dan

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz]

On Thu, Apr 04, 2002 at 03:24:44PM -0500, Daniel Berlin wrote:
> So i'm implementing this, and want to know
> ...
> > /* Return the value N values down from the top of CONTEXT's stack.
> >    This raises an error if there aren't at least N+1 values on the stack.  */
> > ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);
> > 
> 
> How would you like me to raise the error?
> Should i add an error handling function to the dwarf_expr_context struct? 
> Or just call "error", under the assumption that any libdwarf library we 
> write would have error functions of it's own (all the libdwarf's do), and 
> that it'll be the typical printf arguments error function.

[If you go for the latter, please document it clearly in some
header....]

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Jim Blandy]

Daniel Berlin <dan@dberlin.org> writes:
> So i'm implementing this, and want to know
> ...
> > /* Return the value N values down from the top of CONTEXT's stack.
> >    This raises an error if there aren't at least N+1 values on the stack.  */
> > ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);
> > 
> 
> How would you like me to raise the error?
> Should i add an error handling function to the dwarf_expr_context struct? 
> Or just call "error", under the assumption that any libdwarf library we 
> write would have error functions of it's own (all the libdwarf's do), and 
> that it'll be the typical printf arguments error function.

The former.  The function that initializes the context can set it to
something reasonable by default.