headers
H. J. Lu | 1 Jan 2005 20:15

Re: gcc 4.0 generates location list without DW_AT_frame_base

On Fri, Dec 31, 2004 at 02:03:24PM -0800, H. J. Lu wrote:
> On Fri, Dec 31, 2004 at 04:57:17PM -0500, Daniel Berlin wrote:
> > >0x000000000055c84d in add_location_or_const_value_attribute
> > >(die=0x2a96205820,
> > >   decl=0x2a961ad000, attr=DW_AT_location)
> > >   at /export/gnu/src/gcc/gcc/gcc/dwarf2out.c:10108
> > >10108         descr = loc_descriptor (NOTE_VAR_LOCATION
> > >(node->var_loc_note),
> > >(gdb) p *loc_list
> > >$4 = {first = 0x0, last = 0x0, decl_id = 14047}
> > >(gdb)
> > 
> > Oh, that's weird.
> > Wonder why we added it then.
> > anyway, just change
> > if (loc_list)
> > to
> > if (loc_list && loc_list->first)
> 
> I am testing it now. Bootstrap has passed the previous failure. It will
> take a while to finish.

The modified patch works with tls_symbolic_operand in i386. However,
I do see

 <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
     DW_AT_sibling     : <427510>
     DW_AT_abstract_origin: <427159>
     DW_AT_low_pc      : 0x8399aea
     DW_AT_high_pc     : 0x8399b3c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Jan 2005 21:09

Re: gcc 4.0 generates location list without DW_AT_frame_base

On Sat, Jan 01, 2005 at 11:15:00AM -0800, H. J. Lu wrote:
> The modified patch works with tls_symbolic_operand in i386. However,
> I do see
> 
>  <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
>      DW_AT_sibling     : <427510>
>      DW_AT_abstract_origin: <427159>
>      DW_AT_low_pc      : 0x8399aea
>      DW_AT_high_pc     : 0x8399b3c
>  <3><4274a2>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>      DW_AT_abstract_origin: <42716b>
>  <3><4274a7>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>      DW_AT_abstract_origin: <427177>

Do the abstract origins have locations?  Otherwise, that's a problem...

--

-- 
Daniel Jacobowitz
Permalink | Reply | 0 comments |
headers
Daniel Berlin | 1 Jan 2005 21:50

Re: gcc 4.0 generates location list without DW_AT_frame_base

> I do see
>
> <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
>     DW_AT_sibling     : <427510>
>     DW_AT_abstract_origin: <427159>
>     DW_AT_low_pc      : 0x8399aea
>     DW_AT_high_pc     : 0x8399b3c
> <3><4274a2>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>     DW_AT_abstract_origin: <42716b>
> <3><4274a7>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>     DW_AT_abstract_origin: <427177>
> <3><4274ac>: Abbrev Number: 44 (DW_TAG_lexical_block)
>     DW_AT_low_pc      : 0x8399aea
>     DW_AT_high_pc     : 0x8399b3c
> <4><4274b5>: Abbrev Number: 42 (DW_TAG_variable)
>     DW_AT_abstract_origin: <427183>
>     DW_AT_location    : 2 byte block: 91 54    (DW_OP_fbreg: -44)
> [without DW_AT_frame_base]
>
> I assume it is normal.

No.
I'll fix the whole damn thing in a moment the right way (by having it 
verify the nearest enclosing subroutine die has a at_frame attribute and 
using that as the value of can_use_fb)

  >
>
> H.J.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell Shaw | 2 Jan 2005 04:44
Picon

exec

Hi,
When i step into:

   (*func) (program, argv);

gdb exits.

func is execv, and program is "/usr/local/libexec/gcc/avr/3.4.3/cc1"

How do i get into cc1 so i can set breakpoints there?
Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 2 Jan 2005 04:47

Re: exec

On Sun, Jan 02, 2005 at 02:44:55PM +1100, Russell Shaw wrote:
> Hi,
> When i step into:
> 
>   (*func) (program, argv);
> 
> gdb exits.
> 
> func is execv, and program is "/usr/local/libexec/gcc/avr/3.4.3/cc1"
> 
> How do i get into cc1 so i can set breakpoints there?

Run it by hand - gcc -v will show you the command line.  GDB has very
limited support for debugging across exec, depending on your platform.

--

-- 
Daniel Jacobowitz
Permalink | Reply | 2 comments |
headers
Russell Shaw | 2 Jan 2005 08:16
Picon

Re: exec

Daniel Jacobowitz wrote:
> On Sun, Jan 02, 2005 at 02:44:55PM +1100, Russell Shaw wrote:
> 
>>Hi,
>>When i step into:
>>
>>  (*func) (program, argv);
>>
>>gdb exits.
>>
>>func is execv, and program is "/usr/local/libexec/gcc/avr/3.4.3/cc1"
>>
>>How do i get into cc1 so i can set breakpoints there?
> 
> Run it by hand - gcc -v will show you the command line.  GDB has very
> limited support for debugging across exec, depending on your platform.

Hi,
Cc1 runs ok at the command line:

   /usr/local/libexec/gcc/avr/3.4.3/cc1 -quiet -v main.c -quiet -dumpbase main.c -dP -mmcu=atmega16 
-auxbase main -g -O0 -Wall -Wno-unused -version -o /tmp/cccVrfqY.s

When i try to run the same thing in gdb, it crashes:

   Program received signal SIGSEGV, Segmentation fault.
   0x080f3cd1 in init_emit () at ../../gcc-3.4.3/gcc/emit-rtl.c:5354
   /home/russell/SRC/gcc-3.4.3/gcc/emit-rtl.c:5354:138102:beg:0x80f3cd1
   (gdb)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russell Shaw | 2 Jan 2005 10:20
Picon

Re: exec

Russell Shaw wrote:
> Daniel Jacobowitz wrote:
> 
>> On Sun, Jan 02, 2005 at 02:44:55PM +1100, Russell Shaw wrote:
...
> 
> It crashes in emit-rtl.c here:
> 
>   /* Indicate that the virtual registers and stack locations are
>      all pointers.  */
>   REG_POINTER (stack_pointer_rtx) = 1;
> 

oops never mind, i had a spurious '=' sign in the command line
i passed in .gdbinit
Permalink | Reply | 0 comments |
headers
Tobias Grimm | 2 Jan 2005 14:06

gdb vs gdbserver

Hi!

These are my first steps with gdb, but I'm already stuck and need some kind of 
jump start. I would like to debug a multithreaded application (VDR), which works 
fine if I do this "directly" with gdb. Using gdbserver, only one thread is 
created and then everything stops.

What I'm doing is this:

gdbserver host:1000 /usr/bin/vdr-dbg <arguments>

on the same (target-)machine, just another terminal:

gdb /usr/bin/vdr-dbg

(gdb) target remote localhost:1000
Remote debugging using localhost:1000
0x40000c20 in ?? ()
(gdb) c
Continuing.
[New Thread 16384]

And that's it - no other thread is loaded. Running gdb directly works perfectly.

Am I doing something wrong? What can I do to trace down the problem?

bye,

Tobias
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 2 Jan 2005 16:01

Re: gdb vs gdbserver

On Sun, Jan 02, 2005 at 02:06:55PM +0100, Tobias Grimm wrote:
> gdbserver host:1000 /usr/bin/vdr-dbg <arguments>

You are root so that it can open port 1000, right? :-)

> on the same (target-)machine, just another terminal:
> 
> gdb /usr/bin/vdr-dbg
> 
> (gdb) target remote localhost:1000
> Remote debugging using localhost:1000
> 0x40000c20 in ?? ()
> (gdb) c
> Continuing.
> [New Thread 16384]
> 
> 
> And that's it - no other thread is loaded. Running gdb directly works 
> perfectly.
> 
> Am I doing something wrong? What can I do to trace down the problem?

You could give us some information about your target, system,
and version.  And the output of "set debug remote 1".

--

-- 
Daniel Jacobowitz
Permalink | Reply | 1 comment |
headers
Thomas Elam | 2 Jan 2005 17:59
Picon

What are the prescribed ways to extend gdb? Examples?

What are the currently prescribed ways to extend
gdb?  I am interested in adding to gdb: (1) a full
scripting language (not tcl) or (2) a new GUI front-end.
These additions could use the same or different
methods of extending gdb.  I *might* want to link my
code in with gdb.  I much prefer a machine-oriented
interface to a human-oriented one.

I have found the following references about extending gdb:

[1] Section 4.2 of the `GDB Internals' document,
`UI-Independent Output--the ui_out Function':
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_4.html#SEC19

[2] Section 24 of the `Debugging with GDB'
document, `The GDB/MI Interface':
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC223
This is also described in the part of GDB's info page
related to the `-interface' option.

[3] Section A of the `GDB Internals' document, `GDB
Currently available observers':
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_19.html#SEC188

It looks like [2] is the way to go for people
who are not maintainers of gdb.

Examples?  I've found Insight, but I think it links
into gdb and is apparently hard to maintain for that
reason.  As far as I know, most or all of the front-
(Continue reading)

Permalink | Reply | 3 comments |

Gmane