public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Laziness
@ 2005-10-10 20:46 David Lecomber
  2005-10-10 20:50 ` Laziness Daniel Jacobowitz
  0 siblings, 1 reply; 213+ messages in thread
From: David Lecomber @ 2005-10-10 20:46 UTC (permalink / raw)
  To: gdb

Hi Folks,

Take a simple code with a big array...

#include <stdio.h>
int main()
{
  double x[1000][1000];
  printf("hello mum");
}

and ask gdb to "set print elements 1", then break at the printf, and say
"output x".  

It takes a while..  (not as much as it used to on Linux thanks to
the /proc memory reading recently committed) but on other platforms it
literally sucks.

The busy bit of the stack is here:

#6  0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7  0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8  0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9  0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
    at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985


Should we really really be reading all that memory, just to print the
first element?  I mean, not only is that slow, but it imposes a memory
overhead in the GDB too!

Should we be using a better method?

Cheers
David

-- 
David Lecomber <david@lecomber.net>

^ permalink raw reply	[flat|nested] 213+ messages in thread
[parent not found: <200508292030.NAA29909@hpsje.cup.hp.com>]
* backtrace changes current source location
@ 2004-10-26 14:49 Felix Lee
  2004-10-28 13:49 ` Daniel Jacobowitz
  0 siblings, 1 reply; 213+ messages in thread
From: Felix Lee @ 2004-10-26 14:49 UTC (permalink / raw)
  To: gdb list

after doing a backtrace, the current source location is set to
the last frame in the backtrace, which is often main().  this
doesn't seem like useful behavior.  I think backtrace shouldn't
change the current source location at all, but it's been that way
since gdb 5.3.

this is when the change happened:
    http://sources.redhat.com/ml/gdb-patches/2002-08/msg00358.html
any time frame info gets printed, the current source location is
set to that frame, which seems reasonable to me, but it causes
this awkward backtrace behavior.

maybe backtraces should be considered a special case, and
stack.c:backtrace_command_1 should save/restore the current
source location around the call to print_frame_info?
--

^ permalink raw reply	[flat|nested] 213+ messages in thread
* Bumping MI protocol
@ 2004-10-06  1:03 Bob Rossi
  2004-10-06  5:08 ` Nathan J. Williams
  0 siblings, 1 reply; 213+ messages in thread
From: Bob Rossi @ 2004-10-06  1:03 UTC (permalink / raw)
  To: GDB

Hi,

I am wondering when the MI protocol gets bumped. Besides an MI command
that has been changed in an incompatible way, or the actual MI output
syntax changing, does the MI version get bumped for other reasons?

For example, say a new mi command gets added to version 5. Does the mi
version then become 6 because a new command has been added? 

Or does MI5 at one major release have X MI commands available, and MI5
at another major release have Y MI commands available?

Can the conditions for bumping the MI version be enumerated?
Can this information be documented for all to easily understand?

Can a front end developer find all of the functions available to a
specific version of an MI protocol from the documentation?

Thanks,
Bob Rossi

^ permalink raw reply	[flat|nested] 213+ messages in thread
[parent not found: <62E49A52-1639-11D9-8F59-000A9569836A@canids.net>]
* gdbserver, sysroot, prelink
@ 2004-10-04 17:51 Felix Lee
  2004-10-04 18:12 ` Daniel Jacobowitz
  0 siblings, 1 reply; 213+ messages in thread
From: Felix Lee @ 2004-10-04 17:51 UTC (permalink / raw)
  To: gdb list

if you use gdbserver to debug a program on a remote Fedora Core 2
machine, then you need to set solib-absolute-prefix to a copy of
the shared libraries from that specific machine.  you can't use
generic FC2 shared libraries, because 'prelink' in nightly cron
does arbitrary relocation of shared libraries on each machine.

this probably affects any system that uses prelink; I haven't
tried any other than FC2.

I don't think there's anything that needs fixing.  just pointing
out that configuring --with-sysroot is basically useless for any
system that uses prelink.
--

^ permalink raw reply	[flat|nested] 213+ messages in thread
* probing GDB for MI versions
@ 2004-10-03 17:15 Bob Rossi
  2004-10-04  9:00 ` Eli Zaretskii
  2004-10-06 19:16 ` Andrew Cagney
  0 siblings, 2 replies; 213+ messages in thread
From: Bob Rossi @ 2004-10-03 17:15 UTC (permalink / raw)
  To: GDB

Hi,

I want to figure out the best way to probe GDB for the versions of MI
that it supports. If you know of a better way than the one I'm
suggesting below, please let me know.

I want to add a --mi-protocols flag to GDB, and when it is invoked with
this flag, the only thing that it will output is the versions of MI that
it supports each, on it's own line. For example,

gdb --mi-protocols
MI1
MI2
MI3

What does everyone think? With this command, it would be safe to say
that I could always probe GDB to figure out what version of MI the front
end should use with the current GDB.

The only problem with this approach is that it obviously won't work for
GDB's before this command was implemented. However, in that case, the
user can either assume MI1 (if that's the only publically released
version) or they can try MI2.

Thanks,
Bob Rossi

^ permalink raw reply	[flat|nested] 213+ messages in thread
* GDB/XMI (XML Machine Interface)
@ 2004-08-10 20:14 Bob Rossi
  2004-08-10 22:38 ` Kip Macy
                   ` (5 more replies)
  0 siblings, 6 replies; 213+ messages in thread
From: Bob Rossi @ 2004-08-10 20:14 UTC (permalink / raw)
  To: gdb

Hi,

As most of you know, I have been writing a front end to GDB called CGDB.
However, for a while now, I have been a little disappointed with the MI
interface. In my RFC I have described the problems I have with MI and I
have proposed a new method of communication between GDB and the front
end.

If there is good feedback on this RFC, I will continue research on it,
filling in details that I thought would be best to wait until after an
initial acceptance.

If the RFC is accepted by the community I plan on implementing an
initial version of the XMI interface in GDB, and programming CGDB to 
sit on top of GDB. This will at least give the community one open 
source front end to GDB and an example to prove that the new 
machine interface works.

I can't wait to hear your opinions/comments.

Thanks,
Bob Rossi

                       GDB/XMI (XML Machine Interface)

                               Robert Rossi
                               August 2004
                               bob@brasko.net


                             TABLE OF CONTENTS

1. Introduction
  1.1 The Problem
  1.2 The Objective

2. The GDB/XMI Overview
  2.1 Passing Information between GDB and the front end
  2.2 Parsing XMI Commands from GDB's output
  2.3 Parsing the Inferior's output
  2.4 Validation
  2.5 Version Management
  2.6 Understanding the XML data

3. GDB/XMI Specification
  3.1 XMI Types
    3.1.1 Scalar Types
    3.1.2 Compound Types (Structs)
  3.2 A Breakpoint Listing
    3.2.1 The GDB/MI -break-list Specification
    3.2.2 GDB/MI Output
    3.2.3 The GDB/XMI Output
  3.3 A Backtrace
    3.3.1 The GDB/MI -stack-list-frames Specification
    3.3.2 GDB/MI Output
    3.3.3 The GDB/XMI Output

4. A GDB/XMI Example
  4.1 The Inferior's Code
  4.2 GDB/MI Output
  4.3 GDB/XMI Output
  4.4 A Brief Description of the XMI output
    4.4.1 GDB_DISPLAY_PROMPT Document
    4.4.2 GDB_WAITING_FOR_COMMAND Document
    4.4.3 The Front End Transmits a Command
    4.4.4 GDB_INFERIOR_STARTED Document
    4.4.5 GDB_INFERIOR_FINISHED Document

5. Issues to resolve after RFC Initial approval.
  5.1 If GDB will link to libxml, or just output XML
  5.2 How the schema will represent each document sent to the front end
  5.3 Separating GDB output and the Inferior output 
  5.4 If GDB recieves commands in XML

Preface

  GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
  idea of GDB/MI and fixes many of the known issues that GDB/MI contains.

1. Introduction
  1.1 The Problem

  Writing a front end for GDB/MI means that a front end has to be able to
  implement an ad hoc parser, capable of understanding all of the data 
  sent from GDB to it. For each version of GDB, functionality might change, 
  without ever allowing the GUI to understand what the interface differences
  are in a scientific manner. Any guessing from version to version is a 
  best-chance scenario, leaving the front end guessing what functionality
  a CVS snapshot has that has been installed on any particular distribution.

  1.2 The Objective

  The objective of GDB/XMI is to create a reliable protocol between
  GDB and the front end controlling GDB. A goal of this project is to
  remove most of the parsing from the front end, and move it to a
  reliable parsing library, capable of validating the data it is 
  parsing, and building a tree representation of the data without 
  any front end infrastructure. It is believed that the protocol between 
  GDB and any front end can be automated in every front end and that it 
  is not necessary to have any front end developer worry about the syntax
  or grammar of the actual commands sent between GDB and the front end.

  Another goal of this project is to formalize the maintenance and
  version management of the XMI commands, as GDB matures, and modifies the
  XMI commands over time. The front end should be independent of the
  XMI command versions, and should be able to determine what data is
  available to it, without worrying about the version of any particular
  XMI command.
 
  It is believed this can help front end writers in several ways. First,
  there will be a significant reduction of time spent in parsing the 
  obscure MI commands, and understanding what the output represents.
  This gives front end developers a greater chance of actually getting
  to 1.0 on any given front end, and allowing for much more time to 
  be spent on the look & feel of the front end, not including the much
  needed features that most front ends do not have. Secondly, It will
  reduce the code size of each front end, potentially reducing the number 
  of bugs, and allowing for a more reliable set of front ends that sit 
  on top of GDB. 

2. The GDB/XMI Overview

  GDB/XMI is based mostly on the model of GDB/MI. The major differences 
  are the need to pass the information from GDB to the front end via XML
  documents and the ability to give the front end a schema, capable 
  of validating an XMI command.

  2.1 Passing Information between GDB and the front end

  All information passed between GDB and the front end is done in
  the form of an XML document. Each XMI command, generates an XML
  document, and is sent from GDB to the front end.

  2.2 Parsing XMI Commands from GDB's output

  XMI is the protocol between GDB and the front end. It is an XML
  based Markup Language that is intended to be the Machine Interface
  between GDB and any application that would like to communicate with it.
  
  An XML document is started and stopped with escape sequences. These
  sequences tell the front end when an XML document is being sent, and
  when the XML document is done being sent. For each XMI command, GDB 
  will output an escape sequence saying that it is ready to transmit
  the XML Document response. Then it will output the XML Document. Finally,
  GDB will transmit another escape sequence, saying that the document 
  has been completed. This allows the front end to understand what 
  information to pass to the XML parser, and what information is output
  from the inferior.

  2.3 Parsing the Inferior's output
  
  When the GDB sends the XML command stating that the inferior has started, 
  the front end can then parse the output of GDB waiting for an escape
  sequence, saying that the inferior has stopped running. All of the 
  data captured between these two points are output from the inferior.
  It can be processed real time and sent to the user to update them of what 
  the inferior is doing. Any asynchronous commands can of course break the
  stream and output data to the front end, and then notify the front end
  that the inferior has started again. This easily allows the front end
  to understand what data is from GDB and what data is from the inferior.
  The only downside to this design is that escape sequences are needed.
  However, the only way to change that is to allow the inferior's output
  to be on a separate communication link (pipe) than the output of GDB.
  So far, this has not happened. Section 5, point 3 illustrates that it
  would be desirable to split GDB's and the inferior's output up, this
  would cause the protocol between GDB and the front end to not include
  the escape sequences before and after each XMI document sent.

  2.4 Validation
  The validation document (DTD) has to be up to date with the XMI 
  command for the particular version of GDB. Also, this document has to
  be in one place. Therefore, I propose, that an XMI command be given to
  output to the front end all of the XMI validation documents (DTD?) or
  pass a parameter to have GDB output the validation document for a 
  particular XMI command. This document will prove that the XMI commands
  are valid, and GDB is not misbehaving. Front end writers can report
  bad output from GDB easily, and the development process can self-adjust.

  The main goal of this tactic is that GDB is capable of telling front ends
  if the output it is generating is correct. Front ends can use this 
  capability, at virtually no extra cost, to determine if the protocol
  between the two processes is incorrect. By allowing GDB to keep the 
  Schema's, the DRY principle is honored, and things will not get out of
  date.

  2.5 Version Management

  From version to version, XMI commands will be modified. Commands will
  be fully backwards compatible, from version to version, allowing only
  fields to be added, or providing more information than is already 
  there. The front ends will not have to be updated in this way, 
  allowing existing front ends to always be able to use at least the 
  amount of information that they have been programmed to understand.

  Since it is not a perfect world, it is not always possible to make 
  XMI commands backwards compatible. In this case, the XMI command to
  be replaced will be marked as deprecated and a new XMI command will
  be generated to take it's place. This new command will force the 
  front end writer to program the functionality of the new command into
  there program, and from then on, will again have a front end capable
  of parsing the new command with a new GDB, and the old command with 
  the old GDB.

  This model keeps front ends working with both old and new GDB's, which
  is unfortunately a task that most front ends have to and should deal with.

  2.6 Understanding the XML data

  Since all commands are backwards compatible, the tree representation
  for any XMI command can be walked the same way, no matter what version
  of the XMI command is being used. The front end is capable of throwing
  away any data that it does not know how or wish to process, allowing
  it to pick and choose what data is appropriate.

3. GDB/XMI Specification

  3.1 XMI Types

  The XMI types are to be used for validation purposes. They can also
  be used to tell the front end what kind of type a particular element
  is that GDB is sending to the front end.

  3.1.1 Scalar Types

  <int8>      one-byte singed integer
  <uint8>     one-byte unsigned integer
  <int16>     two-byte signed integer
  <uint16>    two-byte unsigned integer
  <int32>     four-byte signed integer
  <uint32>    four-byte unsigned integer
  <int64>     eight-byte signed integer
  <uint64>    eight-byte unsigned integer
  <boolean>   0 (false) or 1 (true)
  <string>    string
  <float>     single-precision signed floating point number
  <double>    double-precision signed floating point number

  3.1.2 Compound Types (Structs)

  A "struct" is a compound value in which accessor name is the only 
  distinction among member values, and no accessor has the same name 
  as any other.

  <struct_example>
    <element_one>one</element_one>
    <element_two>two</element_two>
    <element_three>three</element_three>
  </struct_example>

  A Schema for such a struct could look like this.

  <element name="struct_example">
    <complexType>
      <element name="element_one" type="string"/>
      <element name="element_two" type="string"/>
      <element name="element_three" type="string"/>
    </complexType>
  </struct_example>

  3.2 A Breakpoint Listing

  3.2.1 The GDB/MI -break-list Specification
  The -break-list Command

  Displays the list of inserted breakpoints, showing the following fields:

  `Number'
    number of the breakpoint 
  `Type'
    type of the breakpoint: `breakpoint' or `watchpoint' 
  `Disposition'
    should the breakpoint be deleted or disabled when it is hit: 
    `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
    `y' or `n' 
  `Address'
    memory location at which the breakpoint is set 
  `What'
    logical location of the breakpoint, expressed by function name, 
    file name, line number 
  `Times'
    number of times the breakpoint has been hit 

  If there are no breakpoints or watchpoints, the BreakpointTable body 
  field is an empty list. 

  3.2.2 GDB/MI Output

  -break-list
  ^done,
  BreakpointTable={
    nr_rows="4",nr_cols="6",
    hdr=[
      {width="3",alignment="-1",col_name="number",colhdr="Num"},
      {width="14",alignment="-1",col_name="type",colhdr="Type"},
      {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
      {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
      {width="10",alignment="-1",col_name="addr",colhdr="Address"},
      {width="40",alignment="2",col_name="what",colhdr="What"}
    ],
    body=[
      bkpt={
        number="1",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
      bkpt={
        number="2",type="breakpoint",disp="keep",enabled="y",
        addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
      bkpt={
        number="3",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
      bkpt={
        number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
        what="argc",times="0"}
      ]
    }

  3.2.3 The GDB/XMI Output

  <?xml version="1.0"?>
  <breakpoints>
    <breakpoint>
      <number>1</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804844f</addr>
      <func>main</func>
      <file>test.c</file>
      <line>35</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>2</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>3</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804851d</addr>
      <func>main</func>
      <file>test.c</file>
      <line>61</line>
      <times>0</times>
    </breakpoint>
    <watchpoint>
      <number>4</number>
      <type>watchpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr></addr>
      <what>argc</what>
      <times>0</times>
    </watchpoint>
  </breakpoints>

  3.3 A Backtrace

  3.3.1 The GDB/MI -stack-list-frames Specification

  The -stack-list-frames Command

  Synopsis: -stack-list-frames [ low-frame high-frame ]

  List the frames currently on the stack. For each frame it displays 
  the following info:

  `level'
    The frame number, 0 being the topmost frame, 
    i.e. the innermost function. 
  `addr'
    The $pc value for that frame. 
  `func'
    Function name. 
  `file'
    File name of the source file where the function lives. 
  `line'
    Line number corresponding to the $pc. 

  If invoked without arguments, this command prints a backtrace for 
  the whole stack. If given two integer arguments, it shows the frames 
  whose levels are between the two arguments (inclusive). If the two 
  arguments are equal, it shows the single frame at the corresponding level. 

  3.3.2 GDB/MI Output

  (gdb)
  -stack-list-frames
  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]

  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
  file="test.c",line="13"},frame={level="1",addr="0x080484f5",
  func="main",file="test.c",line="54"}]

  3.3.3 The GDB/XMI Output
    
  <?xml version="1.0"?>
  <stack>
    <frame>
      <level>0</level>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
    </frame>
    <frame>
      <level>1</level>
      <addr>0x080484f5</addr>
      <func>main</func>
      <file>test.c</file>
      <line>54</line>
    </frame>
  </stack>

4. A GDB/XMI Example
  
  4.1 The Inferior's Code
  #include <stdio.h>
  int main(int argc, char **argv){
    printf ( "newline\n" e;
    printf ( "nonewline" );
    return 0;
  }

  4.2 GDB/MI Output
    (gdb)
    -exec-run
    ^running
    (gdb)
    newline
    nonewline*stopped,reason="exited-normally"
    (gdb)

  4.3 GDB/XMI Output
  Assuming that the escape sequence is simply \027
  The whitespace is not necessary, and is simply there for presentation.

  \027<GDB_DISPLAY_PROMPT>
  (gdb) 
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027
  -exec-run
  \027<GDB_INFERIOR_STARTED/>\027
  newline
  nonewline\027<GDB_INFERIOR_FINISHED/>\027
  \027<GDB_DISPLAY_PROMPT>
  gdb
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027

  4.4 A Brief Description of the XMI output
  
    4.4.1 GDB_DISPLAY_PROMPT Document
    The front end receives the document below.
      \027<GDB_DISPLAY_PROMPT>
      (gdb) 
      </GDB_DISPLAY_PROMPT>\027
    The front end sends the data to the XML processor, which then tells
    it that the current prompt is "(gdb) ". The front end can choose to
    do whatever it wants with this information, including display it to the
    user, or just ignore it.

    4.4.2 GDB_WAITING_FOR_COMMAND Document
    Next, GDB transmits the document below.
      \027<GDB_WAITING_FOR_COMMAND/>\027
    The front end receives the data and sends it to the XML processor. The
    processor parses the document and the front end can determine that 
    the command says that GDB is ready to accept a user command. At this
    point, the front end understands that it is OK to transmit a command to
    GDB.

    4.4.3 The Front End Transmits a Command
    The front end transmits the command "-exec-run".
    Should the front end transmit commands in XML or just 
    ordinary text?

    4.4.4 GDB_INFERIOR_STARTED Document
    GDB would send a document telling the front end that the inferior
    has begun processing.
      \027<GDB_INFERIOR_STARTED/>\027
    Everything the front end processes from the pipe from this point 
    until the next GDB XMI Document transmission is from the inferior.
    It is considered to be output that the inferior would like to have
    the user see. The front end can process this data realtime, since
    it does not have to be sent to the XML parser for processing.

    The data
      newline
      nonewline
      is outputted by the inferior, and the front end processes this data
    realtime, understanding that it is not the output of GDB.

    4.4.5 GDB_INFERIOR_FINISHED Document
    GDB would send a document telling the front end that the inferior
    has finished processing.
      \027<GDB_INFERIOR_FINISHED/>\027

    This alerts the front end that GDB is now outputting XMI commands
    again. The front end no longer expects information from the inferior.
    Optionally, GDB could output a XMI command stating that a signal 
    has been caught, or some other asynchronous event has occurred. This
    could be something like
      \027<GDB_SIGNAL_CAUGHT>
      <SIGNAL>
        <NAME>SIGINT</NAME>
        <NUMBER>2</NUMBER>
        <COMMENT>Interrupt from keyboard</COMMENT>
      </SIGNAL>
      </GDB_SIGNAL_CAUGHT>\027
    In this way, GDB could alert the front end of any asynchronous event,
    and no special parsing mechanism will have to take place to 
    understand such actions.

5. Issues to resolve after RFC Initial approval.

  5.1 If GDB will link to libxml, or just output XML
    It would be nice if GDB was capable of sending the XML documents by
    creating them via libxml. However, libxml2 is licensed under the
    MIT license. Also, I don't know if libxml2 is as portable as GDB.

  5.2 How the schema will represent each document sent to the front end
    If there will be one schema for each XMI document, or a schema
    that represents every XMI document.

  5.3 Separating GDB output and the Inferior output 
    If GDB can output it's data on a different pipe than the 
    inferior then the escape sequences would not be needed to tell
    the front end which data is from GDB and which is from the inferior.

    This would simply the front end processing.

  5.4 If GDB recieves commands in XML
    If GDB links in libxml2, then it could easy receive commands from the
    front end in XML. This would be a nice feature, although, since the
    parser in GDB is only written once, it doesn't really matter what format 
    the commands are that is sent to it.

^ permalink raw reply	[flat|nested] 213+ messages in thread
* breaking at for-loop test line
@ 2004-07-29  5:10 Allen Hopkins
  2004-07-29 16:29 ` Daniel Jacobowitz
  0 siblings, 1 reply; 213+ messages in thread
From: Allen Hopkins @ 2004-07-29  5:10 UTC (permalink / raw)
  To: gdb

Is there a way to break at the test statement of a for-loop 
on every iteration, the same way a while-loop works?  Here's
what I mean:

      1	#include <iostream.h>
      2	
      3	int main(int argc, char* argv[])
      4	{
      5	    int i = 0;
      6	
      7	    for (i = 0; i < 3; i++) {
      8	        cout << i << endl;
      9	    }
     10	
     11	    while (i < 6) {
     12	        cout << i++ << endl;
     13	    }
     14	
     15	    exit(0);
     16	}

If I set a breakpoint at line 7, and another at line 11,
and "run" and "continue" until exit, it will only break once
on the for-loop, but it will break on each iteration of the
while-loop.  How does this make sense?  Is there any way to
get a breakpoint at the top of the for-loop to act like the
while-loop?

Here's the compile command:
> g++ -ggdb -Wno-deprecated -o s s.cpp

There's no optimization going on that I'm not aware of,
is there?

Here's sample gdb output:
(gdb) break 7
Breakpoint 1 at 0x10b04: file s.cpp, line 7.
(gdb) break 11
Breakpoint 2 at 0x10b5c: file s.cpp, line 11.
(gdb) run
Starting program: 
/export/home/allenh/projects/metropolis/testing/foodir/s

Breakpoint 1, main (argc=1, argv=0xffbeecac) at s.cpp:7
7	    for (i = 0; i < 3; i++) {
(gdb) c
Continuing.
0
1
2

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
3

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
4

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.
5

Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11	    while (i < 6) {
(gdb) c
Continuing.

Program exited normally.
(gdb)

Any advice appreciated.

Oh, yeah...

	Sun Solaris 2.8
	gcc 3.2.2
	gdb 6.0

Thanks.
-Allen Hopkins
UC Berkeley

^ permalink raw reply	[flat|nested] 213+ messages in thread
* [proposal/testsuite] require build == host
@ 2004-07-25  1:18 Michael Chastain
  2004-07-25  1:52 ` Felix Lee
                   ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Michael Chastain @ 2004-07-25  1:18 UTC (permalink / raw)
  To: gdb

I'm working on a test script for the 'edit' command.  In order to test
the 'edit' command, the test script has to manage files on the host
machine (where gdb is running), not the build machine (where dejagnu is
running).

A recapitulation:

  build    runs dejagnu and the *.exp scripts
  host     runs gcc, as, ld, and gdb
  target   runs the test program such as "callfuncs" or "structs2"

I started looking at how other gdb test scripts work in a configuration
where build and host are different machines, and, well, they don't.
There are about a dozen scripts that compile test files with header
files, and except for list.exp, none of them download their *.h files to
the host machine.  gcore.exp manipulates files that gdb creates on the
host machine.  It needs to "remote upload" the files that gdb creates
back to the build machine, but it doesn't.  And so on.

Of course the test suite supports a target machine which is separate
from the build/host machine.  That is not at issue.

I don't think anyone actually uses a configuration with separate build
and host.  So I propose this patch to document that the gdb test suite
requires that build and host be the same machine.

I'll give this proposal a week for discussion.  I'm hoping that the
discussion goes "you're right, build-cross-host is silly and
unnecessary, just drop it already", but someone may have a good reason
for wanting it.

Testing: I built gdbint.texinfo with makeinfo 4.7 to check the syntax.
But that's not really important yet.  This is about the proposal,
not about the specific patch.

Comments?

Michael C

2004-07-24  Michael Chastain  <mec.gnu@mindspring.com>

	* gdbint.texinfo (Testsuite): Document that build and host
	must be the same machine.

Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.214
diff -c -3 -p -r1.214 gdbint.texinfo
*** gdbint.texinfo	1 Jul 2004 20:25:54 -0000	1.214
--- gdbint.texinfo	25 Jul 2004 00:01:08 -0000
*************** difficult to test, such as code that han
*** 6315,6320 ****
--- 6315,6325 ----
  in particular versions of compilers, and it's OK not to try to write
  tests for all of those.
  
+ DejaGNU supports separate build, host, and target machines.  However,
+ the @value{GDBN} testsuite requires that the host machine be the
+ same as the build machine.  This requirement simplifies the writing
+ of test files.
+ 
  @section Testsuite Organization
  
  @cindex test suite organization

^ permalink raw reply	[flat|nested] 213+ messages in thread
end of thread, other threads:[~2005-10-10 23:53 UTC | newest]

Thread overview: 213+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com>
2004-08-11  0:51 ` GDB/XMI (XML Machine Interface) Chris Friesen
     [not found]   ` <gdb001@speakeasy.net>
2004-08-11  6:28     ` Felix Lee
2004-08-11  8:25       ` Chris Friesen
2004-08-11 22:43     ` Felix Lee
2004-08-12  4:54       ` OT: " Chris Friesen
2004-08-20 10:34     ` Felix Lee
2004-08-20 12:54       ` Bob Rossi
2004-08-20 18:34         ` Daniel Jacobowitz
2004-08-20 18:49           ` Bob Rossi
2004-08-20 18:52             ` Daniel Jacobowitz
2004-08-20 19:25               ` Bob Rossi
2004-08-20 19:42                 ` Daniel Jacobowitz
2004-08-20 19:59                   ` Bob Rossi
2004-08-21 10:25                     ` Eli Zaretskii
2004-08-21 12:34                       ` Bob Rossi
2004-08-21 13:34                         ` Eli Zaretskii
     [not found]         ` <bob@brasko.net>
2004-08-20 18:20           ` Felix Lee
2004-08-20 21:34           ` Felix Lee
2004-08-21 19:21           ` Felix Lee
2004-08-21 20:21             ` Bob Rossi
2004-08-21 19:28           ` Felix Lee
2004-08-21 20:16             ` Bob Rossi
2004-08-21 21:28           ` Felix Lee
2004-08-21 22:37           ` Felix Lee
2004-10-03 18:36           ` GDB/MI snapshots between major release's Felix Lee
2004-10-03 18:40             ` Bob Rossi
2004-10-03 18:42               ` Daniel Jacobowitz
2004-10-03 19:35                 ` Bob Rossi
2004-10-03 19:39           ` Felix Lee
2004-10-03 20:19             ` Bob Rossi
2004-10-04  5:00           ` Felix Lee
2004-10-04 15:34           ` Felix Lee
2004-10-04 15:58             ` Bob Rossi
2004-10-04 16:48           ` Felix Lee
2004-10-04 17:37             ` Bob Rossi
2004-10-04 18:31           ` Felix Lee
2004-10-04 19:00             ` Bob Rossi
2004-10-04 21:07           ` Felix Lee
2004-10-03 17:01             ` Bob Rossi
2004-10-04  5:04               ` Eli Zaretskii
2004-10-04 14:59                 ` Bob Rossi
2004-10-04 15:49                   ` Mark Kettenis
2004-10-04 16:04                     ` Bob Rossi
2004-10-05 10:57                       ` Eli Zaretskii
2004-10-05 14:18                         ` Daniel Jacobowitz
2004-10-06  1:40                           ` Bob Rossi
2004-10-06 11:14                           ` Eli Zaretskii
2004-10-06 11:39                             ` Bob Rossi
2004-10-06 13:19                               ` Eli Zaretskii
2004-10-06 16:55                                 ` Bob Rossi
2004-10-06 17:00                                   ` Paul Koning
2004-10-06 17:02                                     ` Bob Rossi
2004-10-04 21:27             ` Daniel Jacobowitz
2004-10-04 22:14             ` Bob Rossi
2004-10-05  9:03               ` Fabian Cenedese
2004-10-05  9:18                 ` Eli Zaretskii
2004-10-05 13:37                   ` Bob Rossi
2004-10-05 18:53           ` probing GDB for MI versions Felix Lee
2004-10-06 17:14           ` GDB/MI snapshots between major release's Felix Lee
2004-10-06 17:21             ` Daniel Jacobowitz
2004-10-06 18:41           ` Felix Lee
2004-10-06 18:50             ` Bob Rossi
2004-10-06 18:55           ` Bumping MI protocol Felix Lee
2004-10-06 19:43             ` Bob Rossi
2004-10-06 21:04           ` Felix Lee
2004-10-07 18:01           ` probing GDB for MI versions Felix Lee
2004-10-07 19:44             ` Bob Rossi
2004-10-08  8:54               ` Fabian Cenedese
2004-10-19 20:13           ` Felix Lee
2004-10-19 20:23             ` Eli Zaretskii
2004-10-19 21:27             ` Bob Rossi
2004-11-09  2:27             ` Bob Rossi
2005-10-10 20:46 Laziness David Lecomber
2005-10-10 20:50 ` Laziness Daniel Jacobowitz
2005-10-10 21:05   ` Laziness David Lecomber
2005-10-10 21:09     ` Laziness Daniel Jacobowitz
2005-10-10 21:24       ` Laziness David Lecomber
2005-10-10 21:27         ` Laziness Daniel Jacobowitz
2005-10-10 23:53           ` Laziness Paul Hilfinger
     [not found] <200508292030.NAA29909@hpsje.cup.hp.com>
     [not found] ` <1125360166.9350.69.camel@aretha.corp.specifix.com>
2005-08-30  1:13   ` HP gdb/wdb sources available Daniel Jacobowitz
2005-08-30  2:13     ` Paul Hilfinger
  -- strict thread matches above, loose matches on Subject: below --
2004-10-26 14:49 backtrace changes current source location Felix Lee
2004-10-28 13:49 ` Daniel Jacobowitz
2004-10-06  1:03 Bumping MI protocol Bob Rossi
2004-10-06  5:08 ` Nathan J. Williams
2004-10-06 11:27   ` Bob Rossi
2004-10-06 12:30     ` Eli Zaretskii
2004-10-06 16:38       ` Bob Rossi
2004-10-06 16:45         ` Nathan J. Williams
2004-10-06 19:53           ` Bob Rossi
     [not found]       ` <eliz@gnu.org>
2004-10-06 16:57         ` Felix Lee
2004-10-06 17:03           ` Bob Rossi
     [not found] <62E49A52-1639-11D9-8F59-000A9569836A@canids.net>
2004-10-04 19:54 ` GDB/MI snapshots between major release's Jason Molenda
2004-10-04 21:12   ` Bob Rossi
2004-10-04 17:51 gdbserver, sysroot, prelink Felix Lee
2004-10-04 18:12 ` Daniel Jacobowitz
2004-10-03 17:15 probing GDB for MI versions Bob Rossi
2004-10-04  9:00 ` Eli Zaretskii
2004-10-04 13:19   ` Bob Rossi
2004-10-05  9:10     ` Eli Zaretskii
2004-10-05 12:34       ` Bob Rossi
2004-10-06 10:19         ` Eli Zaretskii
2004-10-06 11:47           ` Bob Rossi
2004-10-06 12:13             ` Dave Korn
2004-10-06 16:31               ` 'Bob Rossi'
2004-10-06 16:46                 ` Nathan J. Williams
2004-10-06 16:55                   ` 'Bob Rossi'
2004-10-06 17:04                     ` Nathan J. Williams
2004-10-06 17:15                       ` 'Bob Rossi'
2004-10-06 16:57                 ` Dave Korn
2004-10-06 17:12                   ` 'Bob Rossi'
2004-10-06 17:21                     ` Dave Korn
2004-10-06 17:24                       ` 'Bob Rossi'
2004-10-06 17:31                         ` Daniel Jacobowitz
2004-10-06 17:38                           ` Bob Rossi
2004-10-06 17:41                             ` Dave Korn
2004-10-06 17:55                               ` 'Bob Rossi'
2004-10-06 18:19                                 ` Paul Koning
2004-10-07 10:56                                 ` Dave Korn
2004-10-07 14:15                                   ` 'Bob Rossi'
2004-10-07 14:28                                     ` Dave Korn
2004-10-07 14:37                                       ` 'Bob Rossi'
2004-10-07 14:39                                         ` Dave Korn
2004-10-07 14:50                                           ` 'Bob Rossi'
2004-10-07 15:38                                             ` Dave Korn
2004-10-07 15:49                                               ` 'Bob Rossi'
2004-10-07 16:31                                                 ` Nathan J. Williams
2004-10-07 16:45                                                 ` Alain Magloire
2004-10-07 17:12                                                 ` Dave Korn
     [not found]                                                 ` <200410071614.MAA19648@smtp.ott.qnx.com>
2004-10-08  6:56                                                   ` 'Bob Rossi'
2004-10-08  9:10                                                     ` Eli Zaretskii
2004-10-10 18:13                                                       ` 'Bob Rossi'
2004-10-11 17:46                                                         ` 'Bob Rossi'
2004-10-13 12:14                                                         ` 'Bob Rossi'
2004-10-13 12:48                                                           ` Eli Zaretskii
2004-10-13 14:05                                                             ` 'Bob Rossi'
2004-10-14  7:10                                                               ` Eli Zaretskii
2004-10-14 19:34                                                                 ` 'Bob Rossi'
2004-10-14 21:23                                                                   ` Andrew Cagney
2004-10-15 15:40                                                                     ` 'Bob Rossi'
2004-10-15 13:02                                                                   ` Eli Zaretskii
2004-10-15 13:28                                                                     ` Michael Chastain
2004-10-15 13:42                                                                       ` Eli Zaretskii
2004-10-15 18:04                                                                     ` 'Bob Rossi'
2004-10-16 15:46                                                                       ` Eli Zaretskii
2004-10-16 21:56                                                                         ` 'Bob Rossi'
2004-10-17 18:59                                                                           ` Eli Zaretskii
2004-10-19 13:51                                                                             ` 'Bob Rossi'
2004-10-19 14:18                                                                               ` Daniel Jacobowitz
2004-10-19 19:28                                                                                 ` Bob Rossi
2004-10-19 20:17                                                                                 ` Eli Zaretskii
2004-10-06 18:43                               ` Andrew Cagney
2004-10-06 18:54                                 ` 'Bob Rossi'
2004-10-06 19:19                                   ` Andrew Cagney
2004-10-06 19:25                                     ` 'Bob Rossi'
2004-10-06 17:36                         ` Dave Korn
2004-10-06 17:51                         ` Paul Koning
2004-10-06 18:09                           ` Bob Rossi
2004-10-06 17:05                 ` Alain Magloire
2004-10-06 19:16 ` Andrew Cagney
2004-10-06 19:20   ` Bob Rossi
2004-10-06 20:10     ` Alain Magloire
2004-10-06 20:15       ` Bob Rossi
2004-10-06 20:13     ` Andrew Cagney
2004-10-08 10:28       ` Eli Zaretskii
2004-10-08 18:48         ` Daniel Jacobowitz
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
2004-08-10 22:38 ` Kip Macy
2004-08-11  0:17 ` Michael Chastain
2004-08-11  7:36 ` Fabian Cenedese
2004-08-11  8:51 ` Nick NoSpam
2004-08-11 18:05 ` Bob Rossi
2004-08-11 19:26   ` Alain Magloire
2004-08-11 22:35     ` Jason Molenda
2004-08-12 13:03       ` Nick NoSpam
2004-08-19 23:49 ` Bob Rossi
2004-08-20  7:09   ` Chris Friesen
2004-08-20 12:47     ` Bob Rossi
2004-07-29  5:10 breaking at for-loop test line Allen Hopkins
2004-07-29 16:29 ` Daniel Jacobowitz
2004-07-29 18:58   ` Andre Ancelin
2004-07-30 11:32   ` Eli Zaretskii
2004-08-03 19:21     ` Daniel Jacobowitz
2004-08-03 20:09       ` Andrew Cagney
2004-08-03 20:21         ` Daniel Jacobowitz
2004-07-25  1:18 [proposal/testsuite] require build == host Michael Chastain
2004-07-25  1:52 ` Felix Lee
2004-07-25  2:43   ` Daniel Jacobowitz
     [not found]     ` <drow@false.org>
2004-07-25 22:36       ` Felix Lee
2004-07-26 18:07         ` Michael Chastain
2004-07-27  4:41           ` Felix Lee
2004-07-29 22:21       ` breaking at for-loop test line Felix Lee
2004-07-30  8:23         ` Baurjan Ismagulov
     [not found]           ` <ibr@ata.cs.hun.edu.tr>
2004-07-30 10:46             ` Felix Lee
2004-08-03 18:53               ` Daniel Jacobowitz
2004-08-20 19:06       ` GDB/XMI (XML Machine Interface) Felix Lee
2004-08-20 19:09         ` Daniel Jacobowitz
2004-08-20 19:20       ` Felix Lee
2004-08-21 12:37         ` Bob Rossi
2004-10-04 19:05       ` gdbserver, sysroot, prelink Felix Lee
2004-10-04 19:24         ` Daniel Jacobowitz
2004-10-05 13:03           ` Andrew Cagney
2004-10-05 13:52             ` Daniel Jacobowitz
2004-10-05 13:53       ` Felix Lee
2004-10-06 17:58       ` GDB/MI snapshots between major release's Felix Lee
2004-10-29  8:32       ` backtrace changes current source location Felix Lee
2004-07-25  7:59 ` [proposal/testsuite] require build == host Eli Zaretskii
2004-07-27  0:45 ` Andrew Cagney
2004-07-27  2:31   ` Michael Chastain
2004-07-27  4:16     ` Eli Zaretskii
2004-07-27 15:32     ` Andrew Cagney
2004-07-27 15:50       ` Christopher Faylor
2004-07-27 21:17       ` Michael Chastain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).