headers
Randolph Chung | 1 Mar 2006 02:35
Picon
Favicon

Re: info symbol can crash GDB

Nick Roberts wrote:
> In some cases if the argument to info symbol isn't a number, it causes a
> segmentation fault:
> 
>   (gdb) inf sym 0x8049bb8.
>   Segmentation fault (core dumped)

Which version of gdb is this?

With gdb-6.3 from Debian:
(gdb) inf sym 0x8049bb8.
Invalid number "0x8049bb8.".
(gdb) inf sym 0x8049bb8
No symbol matches 0x8049bb8.

With GNU gdb 6.4.50.20060224-cvs:

(gdb) inf sym 0x8049bb8.
Unexpected type encountered for floating constant.
(gdb) info sym 0x8049bb8
No symbol matches 0x8049bb8.

Can you provide a backtrace on the corefile generated?

randolph
Permalink | Reply | 1 comment |
headers
Wu Zhou | 1 Mar 2006 02:40
Picon
Favicon

Re: New Fortran test failures

On Mon, 27 Feb 2006, Daniel Jacobowitz wrote:

> On Mon, Feb 27, 2006 at 09:31:28PM -0500, Wu Zhou wrote:
> > Here is the fix.  OK to install?
> > 
> > 2006-02-28  Wu Zhou  <woodzltc <at> cn.ibm.com>
> > 
> > 	* f-typeprint.c (f_type_print_base): Delete the redundant space.
> 
> Yeah, this is fine.  Thank you.

Thanks.  Committed.

Here is what I just committed in.

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.7622
diff -c -p -r1.7622 ChangeLog
*** ChangeLog	28 Feb 2006 22:38:03 -0000	1.7622
--- ChangeLog	1 Mar 2006 01:35:29 -0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2006-03-01  Wu Zhou  <woodzltc <at> cn.ibm.com>
+ 
+ 	 * f-typeprint.c (f_type_print_base): Delete the redundant space.
+ 
  2006-02-28  Kevin Buettner  <kevinb <at> redhat.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Roberts | 1 Mar 2006 03:47
Picon

Re: info symbol can crash GDB

 > > In some cases if the argument to info symbol isn't a number, it causes a
 > > segmentation fault:
 > > 
 > >   (gdb) inf sym 0x8049bb8.
 > >   Segmentation fault (core dumped)
 > 
 > Which version of gdb is this?

GNU gdb 6.4.50.20060228-cvs on Fedora Core 3

 ...
 > Can you provide a backtrace on the corefile generated?

I think previously I followed execution into c_parse and had to preserve a
file like c-exp.y.tmp, but I lost the plot because I'm not familiar with
bison.  Anyway the backtrace might have changed now.

Nick

#0  0x0813004b in check_typedef (type=0x0) at gdbtypes.c:1384
#1  0x080e8071 in allocate_value (type=0x0) at value.c:217
#2  0x080e9d90 in value_from_double (type=0x0, num=<invalid float value>) at value.c:1560
#3  0x080eada2 in evaluate_subexp_standard (expect_type=0x0, exp=0x9454410, pos=0xfefc8654,
noside=EVAL_NORMAL) at eval.c:447
#4  0x080ea09f in evaluate_subexp (expect_type=0x0, exp=0x9454410, pos=0xfefc8654,
noside=EVAL_NORMAL) at eval.c:72
#5  0x080ea284 in evaluate_expression (exp=0x9454410) at eval.c:162
#6  0x080ea0dd in parse_and_eval_address (exp=0x93c09a8 "0x8049bb8.") at eval.c:87
#7  0x080fb357 in sym_info (arg=0x93c09a8 "0x8049bb8.", from_tty=1) at .././gdb/printcmd.c:1021
#8  0x080b4f4f in do_cfunc (c=0x93d82f8, args=0x93c09a8 "0x8049bb8.", from_tty=1) at .././gdb/cli/cli-decode.c:57
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos Eduardo Rodrigues de Almeida | 1 Mar 2006 05:03
Picon

Bug in MI command -data-dissasemble ??

Hi all,
I was trying the -data-disassemble command and I found something strange.
I think with a session I can explain better:

[eduardo <at> ~/lab3/Debug]$gdb -i=mi2
~"GNU gdb 6.4\n"
~"Copyright 2005 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and
you are\n"
~"welcome to change it and/or distribute copies of it under certain
conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for
details.\n"
~"This GDB was configured as \"x86_64-pc-linux-gnu\"."
~"\n"
(gdb)
-file-exec-and-symbols lab3
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
^done
(gdb)
-data-disassemble -f /home/eduardo/libgip/src/gip_app.cpp -l 68 -n 1 -- 1
&"mi_cmd_disassemble: Invalid line number\n"
^error,msg="mi_cmd_disassemble: Invalid line number"
(gdb)
-data-disassemble -f gip_app.cpp -l 68 -n 1 -- 1
^done,asm_insns=[{address="0x000000000040d7e0",func-name="_Z12gip_app_initPc",offset="0",inst="mov
   %rbx,0xfffffffffffffff0(%rsp)"}]
(gdb)
-data-disassemble -f /home/eduardo/libgip/src/gip_app1.cpp -l 68 -n 1 -- 1
(Continue reading)

Permalink | Reply | 6 comments |
headers
Randolph Chung | 1 Mar 2006 16:12

RFC: getting rid of deprecated_hp_som_som_object_present

Recently on gdb-patches there was some mention of this deprecated flag. 
I'd like to get some comments/feedback on how to clean this up....

Here are the parts of gdb that uses this flag:

- symtab.c defines this variable
- hppa-hpux-tdep.c initializes this to 0 for each newly created inferior
it also uses this to help determine if we should use the special hp c++ 
exception support
- hpread.c sets this variable to 1 if we read a file with HP debug 
information
- eval.c uses this to decide to punt if we try to do something with a 
pointer to member function, or to apply a bias for a pointer to member 
variable
- parse.c has a reference to this in a function named 
parse_nested_classes_for_hpacc, but this code apparently is no longer 
used anywhere in gdb
- valops.c uses this in value_cast to handle casting things from a 
pointer to member function/variable to an int or enum
- c-typeprint.c uses this to print extra info for "sized enums"
- cp-valprint.c uses this in cp_print_class_method to handle class 
member functions (I think)

Most of these have to do with how gdb handles c++ methods and member 
variables, which makes me think that perhaps we should add some hooks to 
the cp-abi layer to handle the type conversion logic. This takes care of 
eval.c, valops.c, and maybe cp-valprint.c

I'll have to dig through some cvs history to figure out what we want to 
do with the bits in parse.c
(Continue reading)

Permalink | Reply | 5 comments |
headers
Randolph Chung | 1 Mar 2006 16:22

hpux build errors, and -Werror

Currently on hppa64-hp-hpux11.11, gdb fails to build with -Werror 
because we are not getting the const flag correct with iconv() calls.

gdb's configure script actually has some tests for this, from 
acinclude.m4, however, the test doesn't actually work (at least in this 
case), because configure doesn't compile the test program with -Werror, 
and the resultant warning doesn't trigger the script to define ICONV_CONST

I'm not very good with autoconf & friends and can't figure out the right 
way to fix it. Can somebody give me some hints?

On hppa2.0w-hp-hpux11.11, there is a different problem, at least on the 
system I'm testing on:

ser-tcp.c:209 has a call to getsockopt. This causes a (fatal) warning:
../../gdb/gdb/ser-tcp.c:209: warning: passing arg 5 of `getsockopt' from 
incompatible pointer type

getsockopt is declared as:
extern int getsockopt (int, int, int, void *, int *);
whereas socklen_t is:
typedef long unsigned int size_t
typedef size_t socklen_t;

I would argue the headers are broken on this platform, but nonetheless 
we may need to find a way to workaround this in gdb. I can't think of 
any good way to do this though.

Comments appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Brobecker | 2 Mar 2006 02:01
Favicon

ia64-hpux GDB based on gdb-6.3

Hello all,

Just a quick note to say that AdaCore has ported GDB to ia64-hpux
a while ago. I am definitely planning to contribute this port and
offer it for inclusion in the FSF tree, but I'm really short on time
these days.

There are also a couple of things I haven't finished with it that I'd
like to work on too. For instance, I haven't had time to implement
core file support. It's going to take a little bit of time because it's
an area of BFD and GDB I'm not very familiar with, particularly BFD.
Perhaps I should still contribute this port without this?

But for those of you who are curious or interested, check out our
sources on libre.adacore.com (GDB for Ada snapshot section).

--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 2 Mar 2006 02:14

Re: ia64-hpux GDB based on gdb-6.3

On Wed, Mar 01, 2006 at 05:01:10PM -0800, Joel Brobecker wrote:
> There are also a couple of things I haven't finished with it that I'd
> like to work on too. For instance, I haven't had time to implement
> core file support. It's going to take a little bit of time because it's
> an area of BFD and GDB I'm not very familiar with, particularly BFD.
> Perhaps I should still contribute this port without this?

Yes - it's still functional without that.  But it's really not very
hard.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Jim Blandy | 2 Mar 2006 06:57
Favicon

Re: RFC: getting rid of deprecated_hp_som_som_object_present

On 3/1/06, Randolph Chung <randolph <at> tausq.org> wrote:
> Any thoughts? Is this even worth touching/fixing?

"Worth"?  I'm always tempted to assess the "worth" of a project by how
ugly what it would fix is... :)  I think that global variable is
really terrible.  And as the Modula-2 example showed, the change is
getting propagated around.

Given that C99 specifies that enum values are ints, would it make
sense to always print enum values specially if the the enum type's
size is not equal to that of builtin_type_int?
Permalink | Reply | 0 comments |
headers
D.J. Barrow | 2 Mar 2006 10:26
Picon
Favicon

are windriver violating GPL

Hi all,
They are using gdb in tornado & are charging upto
24000 sterling for floating annual licences but they haven't released the source code.

D.J. Barrow Linux kernel developer
eMail: dj_barrow <at> ariasoft.ie 
Home: +353-22-47196.
Mobile (IRL) +353-(0)86 1715438

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
Permalink | Reply | 5 comments |

Gmane