headers
Daniel Jacobowitz | 2 Oct 2005 22:19

Re: [patch] clean up potential memory leak in thread.c

On Thu, Sep 29, 2005 at 01:18:41PM -0400, Kris Warkentin wrote:
> Got rid of a 'FIXME' by implementing a target hook for cleaning up 
> private thread info.  Look kosher?

I assume you have some target data that you need to get rid of for QNX? 
Most other threaded targets have found a single struct sufficient, so
I'm mildly curious what you need.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 2 Oct 2005 22:57

Re: [RFC] Decimal Floating Point support for GDB (Part 1: patch)

On Wed, Sep 28, 2005 at 12:42:36PM +0800, Wu Zhou wrote:
> This patch is intended to add decimal floating point (DFP) support into
> GDB.  It currently supports the printing and setting of DFP.  And also 
> support displaying the dfp types in function argument and backtrace.  
> If you think that any other features are also desired, please let me know.  
> I will try to see whether it can also be supported.

I'm afraid I am not very happy with this approach :-(

	* c-exp.y (parse_number): Parse the decimal floating point, which 
	has a suffix ('df', 'dd' or 'dl') and return STRING here.

This certainly isn't right.  It produces several problems:

(gdb) p 1.2df
evaluation of this expression requires the target program to be active

[Side effect of string handling]

...

(gdb) p 1.2df
$1 = "1.2"

(gdb) p $1[1]
$2 = 46 '.'

(gdb) p (1.2df)
A syntax error in expression, near `'.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Daniel Jacobowitz | 2 Oct 2005 23:00

Re: [RFC] Decimal Floating Point support for GDB (Part 2: testcase)

On Wed, Sep 28, 2005 at 01:28:07PM +0800, Wu Zhou wrote:
> In this testcase, there are totally 83 tests.  Most of them are about 
> displaying and setting of dfp types, which are partitioned into 
> three groups, one for each dfp types (_Decimal32, _Decimal64 and 
> _Decimal128).  In each group, we first begin with the printing of 
> a normal finite dfp value, then Infinity and NaN. Then we call 
> d32_set_tests (d64_set_tests or d128_set_tests) to test that GDB 
> could handle the setting different values of variable d32 (d64 or 
> d128).
> 
> At the end of the testcase, we test that GDB could print out the dfp
> values correctly in the function arguments and backtrace.

Just a few comments on the tests:

- This should be at least two separate tests, since the "p 1.5df" tests
can be run without a GCC which supports DFP, even though dfp-test.c
can't be compiled.

- C files need to have copyright headers.

In this:

> +     gdb_test "p d32=123.45df" "123.45df" "p d32=123.45df"

- The third argument to gdb_test defaults to the first argument, so you
don't need it.

- The second argument should be more specific.  Something like
"\$${decimal} = 123.45df".  I went to look at this test to see if my
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 3 Oct 2005 00:21

Removing TYPE_VPTR_FIELDNO uses (was: Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class)

On Thu, Sep 29, 2005 at 12:53:18AM -0400, Wu Zhou wrote:
> - gnu-v2-abi.c is for an old ABI.  Not relevant.
> - stabsread.c is for a different debug format.  Not relevant.
> - dwarf2read.c: to read out data for VPTRs if there are any. No need for
> any change IMO.

Yes, I agree.

> - gdbtypes.c/gdbtype.h: to initialize VPTR_FIELDNO (in alloc_type and
> create_array_type), fill VPTRs (in fill_in_vptr_fieldno), and dump VPTRs
> (in recursive_dump_type).  Maybe some change to the type dumping is
> needed.

Not if we leave them for older ABIs and stabs.

> - varobj.c (cplus_class_num_children and cplus_name_of_child): The code
> will ignore VPTRs when iterating thru the base classes.  I don't know
> the way how to iterate thru the base classes if there is no dependence
> for VPTRs.  Maybe we need to find a way for that?

For this code, it may suffice to ignore DW_AT_artificial fields and
make sure that the vptr is tagged as artificial.  Or, call a new C++
ABI method (cp-abi.h) to check for vptrs and ignore them.

> - eval.c (evaluate_subexp_standard): TYPE_VPTR_BASETYPE is used to iterate
> the baseclasses to find the real address of the virtual function.

This code needs to be (A) read and thought about, so that we can figure
out what it used to do, and (B) replaced with something less broken. 
It hasn't worked in forever.  Take a look at what METHOD_PTR_IS_VIRTUAL
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Jacobowitz | 3 Oct 2005 00:27

Re: Fix PR1659

On Wed, Sep 28, 2005 at 05:11:18PM +0930, Alan Modra wrote:
> Obvious fixes.  OK to apply?
> 
> 	PR 1659
> 	* rs6000-tdep.c (rs6000_push_dummy_call): Correct size of
> 	backchain write.
> 	(rs6000_convert_from_func_ptr_addr): Correct comment

I can't get at gnatsweb at the moment to read the PR, but the fix
is definitely obvious.  OK.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 3 Oct 2005 00:31

Re: Fix powerpc64-linux inferior function calls

On Wed, Sep 28, 2005 at 05:03:45PM +0930, Alan Modra wrote:
> This gives me a gdb that can make inferior calls on powerpc64-linux when
> debugging code compiled by a gcc that doesn't provide dot-symbols.
> ppc-sysv-tdep.c:convert_code_addr_to_desc_addr needs dot-symbols to find
> the function descriptor corresponding to a given pc.
> 
> It's a band-aid really.  I think the proper fix is to not convert
> function pointers to function code addresses in gdb's expression
> evaluator, which would keep the pointer to the descriptor.  This of
> course would mean that gdb's breakpoint and similar code expecting that
> function symbols point to code would need adjusting.  One benefit would
> be that "p *func" would print me the descriptor, which is what I'd
> expect for powerpc64.
> 
> 	PR 2016
> 	* elfread.c (elf_symtab_process): Split out from..
> 	(elf_symtab_read): ..here.
> 	(elf_symfile_read): Read both static and dynamic symbols before
> 	processing.  Call bfd_get_synthetic_symtab.

Why do we need to read both before processing either?  I'm thinking of
the patch I posted here:
    http://sourceware.org/ml/gdb-patches/2005-06/msg00220.html           
and pinged a few weeks ago.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
(Continue reading)

Permalink | Reply | 11 comments |
headers
Daniel Jacobowitz | 3 Oct 2005 00:42

Re: [RFA] print arrays with indexes

On Mon, Sep 26, 2005 at 06:04:20PM -0700, Joel Brobecker wrote:
> BTW: I think you are using vim, IIRC. Do you have some magic settings
> that handles that handles the tabs for you. If I were able to have tabs
> automatically created after I create spaces, and also transformed into
> spaces when I backspace into them, as well as allowing me to go through
> them as if they were spaces, I wouldn't mind the tabs so much.

No, sorry; I use a bastard combination of emacs and joe for most of my
code editing.  Can't help you with Vim.

> +  if (TYPE_CODE (index) == TYPE_CODE_RANGE)
> +    index = TYPE_TARGET_TYPE (index);
> 
> which the function used to have. I couldn't understand why this
> was necessary, and a look at where the type was used showed that
> this was not necessary, as ada_print_scalar, the only eventual consumer
> of that type, knew how to handle range types. I would think the same is
> true of all other languages, right?

Not sure what you mean by "used to have", to be honest.  I guess this
code had some prior life in an ACT tree, if you didn't write it?  It
seems like the sort of check that only Ada would need.

And, this code is still in the patch below.  It's definitely dead code,
though, so I assume you meant to remove it.

Should the "return 0;" cases in get_array_low_bound be errors? Or even
internal errors (probably not)?  There's already lots of code that uses
TYPE_LOW_BOUND (TYPE_INDEX_TYPE (array_type)).  If that's not valid, we
need to know why not.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Daniel Jacobowitz | 3 Oct 2005 00:45

Re: [RFA/testsuite] New testcase for "set print array-indexes"

On Mon, Sep 26, 2005 at 03:50:56PM -0700, Joel Brobecker wrote:
> 2005-09-26  Joel Brobecker  <brobecker <at> adacore.com>
> 
>         * gdb.base/arrayidx.c: New file.
>         * gdb.base/arrayidx.exp: New testcase.

When we're done with the GDB patch, this is OK.  Please fix one thing:

> 
> # This file is part of the gdb testsuite.  It is intended to test that
> # gdb could correctly handle floating point constant with a suffix.

Needs to be updated.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 3 Oct 2005 01:01

Re: Patch: fix gdb_gcore.sh failure in ash/dash

On Mon, Sep 26, 2005 at 09:17:16AM +0200, Mark Kettenis wrote:
> > On Sat, Sep 17, 2005 at 06:26:49PM -0400, Daniel Jacobowitz wrote:
> >> 2005-09-17  Daniel Jacobowitz  <dan <at> codesourcery.com>
> >>
> >> 	* gdb_gcore.sh: Use a temporary file.  Use gdb from $PATH.
> >
> > Did you have any comments on the revised patch, Mark?  Otherwise I'll
> > check this in.
> 
> Sorry, been to busy making OpenBSD work on my new iMac G5 ;-)
> 
> Yes this is exactly what I had in mind.  Please go ahead and commit.

Checked in, then.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 0 comments |
headers
Alan Modra | 3 Oct 2005 01:22
Picon

Re: Fix powerpc64-linux inferior function calls

On Sun, Oct 02, 2005 at 06:31:18PM -0400, Daniel Jacobowitz wrote:
> > 	(elf_symfile_read): Read both static and dynamic symbols before
> > 	processing.  Call bfd_get_synthetic_symtab.
> 
> Why do we need to read both before processing either?

The powerpc64 get_synthetic_symtab will use both dynamic and static
symbol tables.  Handy when debugging stripped objects.  So both symbols
tables need to be read before calling bfd_get_synthetic_symtab.

>  I'm thinking of
> the patch I posted here:
>     http://sourceware.org/ml/gdb-patches/2005-06/msg00220.html           
> and pinged a few weeks ago.

Which I see you do in this patch too.  I didn't know about your patch
when I wrote mine..  The order of processing doesn't matter at all.
It just fell out that way in my patch.  Incidentally, why did you
need to fudge the synthetic syms?

+	  /* Synthetic symbols are not, strictly speaking, either local
+	     or global.  But we can treat them as global symbols, since
+	     they are effectively dynamic symbols.  */
+	  synth_symbol_table[i]->flags |= BSF_GLOBAL;

Seems like this should be done in bfd if necessary.

--

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre
(Continue reading)

Permalink | Reply | 10 comments |

Gmane