Re: Program received signal SIGFPE, Arithmetic exception
Date: Tue, 27 Nov 2012 09:01:39 -0800 (PST) From: Alexandre Furlan alexandrepfur...@gmail.com I have the program a FORTRAN90 and when I debug with gdb, is shown Program received signal SIGFPE, Arithmetic exception. 0x004060be in MAIN__ () How to find the line where the error was found ? Did you try typing bt, short for backtrace? ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Program received signal SIGFPE, Arithmetic exception
Date: Tue, 27 Nov 2012 16:14:04 -0200 (BRST) From: alexandrepfurlan alexandrepfur...@gmail.com cc: Alexandre Furlan alexandrepfur...@gmail.com, bug-gdb@gnu.org I tried, and the result is Program received signal SIGFPE, Arithmetic exception. 0x004060be in MAIN__ () (gdb) bt #0 0x004060be in MAIN__ () And now ? Did you compile with -g? It looks like there are no debug info in this executable. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Tue, 10 Jul 2012 22:39:58 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document This warning is no longer there, it was not clearly wrong in formats other than TeX, and we don't want to have something specific for output formats. This issue will be revisited later, but in the mean time this one is no longer there... Thank you. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Sat, 23 Jun 2012 13:29:38 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 10:54:15PM +0300, Eli Zaretskii wrote: I don't think so. If I am not wrong, a colon means that there is a label before the node name, but it still leads to a cross reference. That's true, but an asterisk '*' cannot be a valid label, I can't see why. Because of * Menu. and there should be a blank after *Note before the label. That, I could agree with. I'll ask on the list. Thanks. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Sat, 23 Jun 2012 15:07:38 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
You missed my point. The manual is formatted fine, but since it uses an
undocummented Texinfo feature it is in a bad shape Texinfo-wise and the
formatting could change in the future, more or less drastically.
If you make such backwards incompatible changes in behavior, people
will complain, and rightly so.
Not rightly. Undocumented features should not be counted on.
But they are, all the time. Breaking that causes users to complain,
and insisting on breaking them makes maintainers look unfriendly.
How is an empty argument to @w any better than an empty @item? One
day someone might even decide that such empty arguments to @w don't
make sense, and will produce a warning for that, too.
Sure, unless the fact that an empty @item is wrong but an @item with an
empty @w{} is correct is documented in the manual, in which case it
becomes 'set in stone' that this is a correct construct.
First, we should agree that one is right while the other is wrong,
and for that we need a good reason to reject the 'wrong one.
And second, documenting things rarely makes them set in stone,
because users have a habit of rejecting unreasonable (from their POV)
restrictions, even if they are documented.
A user-friendly tool lets users do whatever they want, so long as the
result is to users' liking. If I learned anything from the days back
when I was hacking makeinfo, it's that users will use the tools in
every imaginable way and some unimaginable ones. Restricting them or
annoying them with gratuitous messages, without a very good reason, is
just annoyance.
I interpret your point in the exact opposite direction. To me, the fact
that 'users will use the tools in every imaginable way and some
unimaginable ones' means that users should only have expectations on the
documented features, and that we may want to precise the right ways
at any time.
This doesn't work in practice, and I hope Texinfo will not go that
way.
If you look at the manual, the @top is in an @ifnottex block, but
the idea is that the rule about @contents should not depend on the
output format.
If there's no good reason for a rule, it simply should not exist.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 15:50:29 +0200 From: Patrice Dumas pertu...@free.fr Cc: bug-gdb@gnu.org, k...@freefriends.org On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote: ./gdb.texinfo:22939: warning: @table has text but no @item Why is this warning needed? This one is clear to me. A @table without @item does not make sense. A @table specifies a series of headings and associated texts, so a @table without @item has no reason to be. I don't think this warning should be ignored. Maybe use @group? Or @quotation? IMO, this is wrong in principle. It is not makeinfo's business to force style on the author of the manual. Warnings should only be emitted when the produced manual is in bad shape. This isn't such a case, so the warning is IMO gratuitous. If you want a pedantic mode (which could be a useful feature), please make it optional. What are you searching for with those empty tables? Indentation and consistent format of describing GDB features. ./gdb.texinfo:35330: warning: @item missing argument And this one? @table is for a succession of headings and text. An empty item means no heading and thus is not suitable. It doesn't come out empty in the output. Did you look at that? It produces this: `' which stands for an empty response. If you know of any other way of getting the same in a @samp typeface, please tell. I agree that it may make sense as a separator, to control the presentation, but the general idea is that Texinfo should not be used as a presentational markup, but instead as a descriptive markup, hence this warning. Again, this is wrong philosophy. This warning should at least be turned off by default. You can always ignore that warning, though. Extra noise runs the risk of obscuring real problems. ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document That @contents _is_ at the beginning. What's the issue here? It is not at the very beginning, instead, it appears at the end of the top node and element. At the beginning would mean before @node Top But the Texinfo manual documents no such restriction. It says only this: Both contents commands should be written on a line by themselves, and are best placed near the beginning of the file, after the `@end titlepage' (*note titlepage::). This is clearly an advisory, not a requirement. So I don't think a warning is called for. You can ignore this warning, though. I don't want to ignore warnings. Please don't introduce warnings that should be ignored. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 15:58:57 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 05:56:49AM +0300, Eli Zaretskii wrote:
Date: Wed, 20 Jun 2012 22:37:53 +0200
From: Patrice Dumas pertu...@free.fr
Cc: Karl Berry k...@freefriends.org
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines
--10%--
Cannot find node `a trace experiment and data collection may stop
automatically
Then perhaps the stand-alone Info reader should be fixed instead.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 19:18:19 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 07:15:47PM +0300, Eli Zaretskii wrote:
On Thu, Jun 21, 2012 at 05:52:55AM +0300, Eli Zaretskii wrote:
./gdb.texinfo:22939: warning: @table has text but no @item
Why is this warning needed?
This one is clear to me. A @table without @item does not make sense. A
@table specifies a series of headings and associated texts, so a @table
without @item has no reason to be. I don't think this warning should be
ignored. Maybe use @group? Or @quotation?
IMO, this is wrong in principle. It is not makeinfo's business to
force style on the author of the manual. Warnings should only be
emitted when the produced manual is in bad shape. This isn't such a
case, so the warning is IMO gratuitous.
This warning was primarily done to help writers avoid mistakes, after a
user demand (if I recall well).
That demand would be satisfied by an optional warning. E.g., like
with GCC's -Wfoo switches.
As to whether this means that the manual is in bad shape, I would be
tempted to say that it is the case.
Here's the output that empty table produces:
The following attributes are provided:
-- Variable: Value.address
If this object is addressable, this read-only attribute holds
a `gdb.Value' object representing the address. Otherwise,
this attribute holds `None'.
-- Variable: Value.is_optimized_out
This read-only boolean attribute is true if the compiler
optimized out this value, thus it is not available for
fetching from the inferior.
-- Variable: Value.type
The type of this `gdb.Value'. The value of this attribute is
a `gdb.Type' object (*note Types In Python::).
Do you see anything bad shape here? I don't.
The presentation of the text appearing before the first @item could
be formatted differently from the text appearing after the first @item,
so you cannot rely on having the presentation you want in the future.
It could even be discarded, be considered as a 'meta-data' (the table
title?). This is left unspecified for now in the manual such that we
can give any meaning to this text in the future.
If you make such backwards incompatible changes in behavior, people
will complain, and rightly so.
It doesn't come out empty in the output. Did you look at that? It
produces this:
`'
Indeed, I missed it.
which stands for an empty response. If you know of any other way of
getting the same in a @samp typeface, please tell.
There is, for example:
@item @w{}
How is an empty argument to @w any better than an empty @item? One
day someone might even decide that such empty arguments to @w don't
make sense, and will produce a warning for that, too.
The GDB manual has been using this form for a very long time now. So
long that it could definitely be considered an established de-facto
practice.
However if the table is formatted with @asis, there is no output.
That's true, but this is not an @asis table. If you want to limit
this warning to @asis, I'd be fine with that.
Should that be documented?
Not sure what you suggest to document.
I agree that it may make sense as a separator, to control the
presentation, but the general idea is that Texinfo should not be
used as a presentational markup, but instead as a descriptive
markup, hence this warning.
Again, this is wrong philosophy.
This is not a wrong philosophy, in my opinion this is the philosophy
behind Texinfo.
A user-friendly tool lets users do whatever they want, so long as the
result is to users' liking. If I learned anything from the days back
when I was hacking makeinfo, it's that users will use the tools in
every imaginable way and some unimaginable ones. Restricting them or
annoying them with gratuitous messages, without a very good reason, is
just annoyance.
This warning should at least be turned off by default.
I am not sure, as the output may not be what the writer intended.
It is today.
Again, the empty @item line could either be ignored, or be considered as
an empty line depending on the formatter.
makeinfo never did such things, and IMO it never should.
./gdb.texinfo:190: warning: @contents should only appear at beginning
or end of document
That @contents _is_ at the beginning. What's the issue here?
It is not at the very beginning, instead, it appears at the end of the
top node and element. At the beginning would mean before
@node Top
But the Texinfo manual documents no such restriction. It says only
this:
Both contents commands should be written on a line by themselves, and
are best placed near the beginning of the file, after the `@end
titlepage' (*note titlepage::).
This is clearly an advisory, not a requirement
Re: warnings with cvs texinfo version
Date: Thu, 21 Jun 2012 19:24:51 +0200
From: Patrice Dumas pertu...@free.fr
Cc: bug-gdb@gnu.org, k...@freefriends.org
On Thu, Jun 21, 2012 at 07:17:40PM +0300, Eli Zaretskii wrote:
./gdb.texinfo:11503: warning: @strong{Note...} produces a spurious
cross-reference in Info
No, it doesn't, not with a colon immediately following the Note.
My testing shows that it indeed does, at least with info (GNU texinfo)
4.13.
*Note*: a trace experiment and data collection may stop
-Info: (gdb.info)Starting and Stopping Trace Experiments, 123 lines
--10%--
Cannot find node `a trace experiment and data collection may stop
automatically
Then perhaps the stand-alone Info reader should be fixed instead.
I don't think so. If I am not wrong, a colon means that there is a label
before the node name, but it still leads to a cross reference.
That's true, but an asterisk '*' cannot be a valid label, and there
should be a blank after *Note before the label.
FWIW, the Emacs Info reader doesn't have any problems figuring out
that this isn't a cross-reference. So perhaps the stand-alone reader
should follow suit.
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: warnings with cvs texinfo version
Date: Wed, 20 Jun 2012 22:37:53 +0200 From: Patrice Dumas pertu...@free.fr Cc: Karl Berry k...@freefriends.org The following warnings remain when using the cvs makeinfo version. It is unclear to me how to solve these, but hipefully, you should be able to fix them, or bear with warnings: Thanks, but... ./gdb.texinfo:22939: warning: @table has text but no @item Why is this warning needed? ./gdb.texinfo:35330: warning: @item missing argument And this one? ./gdb.texinfo:190: warning: @contents should only appear at beginning or end of document That @contents _is_ at the beginning. What's the issue here? ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: fixes in the texinfo documentation
Date: Fri, 15 Jun 2012 02:43:35 +0200 From: Patrice Dumas pertu...@free.fr Cc: Karl Berry k...@freefriends.org Please find attached a patch for the gdb documentation that fixes issues such as @itemx instead of @item, empty @item, a missing @node, @menu entries order inconsistent with respect with sectioning, and @@ to be protected in @tex comments. Thanks, committed. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: [PATCH] gdb/doc/gdb.texinfo (@menu): fix a typo: s/dump/to dump/
From: Jim Meyering j...@meyering.net Date: Wed, 11 Feb 2009 09:56:34 +0100 -* Core File Generation::Cause a program dump its core +* Core File Generation::Cause a program to dump its core Are you sure this is incorrect English? ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: [PATCH] gdb/doc/gdb.texinfo (@menu): fix a typo: s/dump/to dump/
From: Jim Meyering j...@meyering.net Cc: bug-gdb@gnu.org Date: Wed, 11 Feb 2009 21:40:28 +0100 -* Core File Generation::Cause a program dump its core +* Core File Generation::Make a program dump its core That sounds much better, thanks. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: problem with info symbol
Date: Sat, 3 Jan 2009 23:45:20 -0800 (PST) From: M Jalili work1...@yahoo.com i compile my c program with gcc 4.3.1 by this command: gcc -o prog1.out prog1.c -ggdb then is use gdb to fetch some information in run time. gdb -e prog1.out -s prog1.out and when is use info symbol var1 (var1 is a variable)i receve this message: symbol var1 is a variable with complex or multiple location. (dwarf2) please help me. Compile with -O0, and if that doesn't help, declare var1 as `volatile'. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Use GDB to debug MSVC generated executables and shared libraries.
From: Naresh Vankayalapati [EMAIL PROTECTED] Date: Thu, 30 Nov 2006 15:24:09 -0500 Cc: I wanted to know if there is a way to use these debuggers to debug executables generated using MSVC. You cannot use GDB to debug MSVC-compiled programs on the source level. GDB doesn't understand the proprietary format of Microsoft PDB debug information. You _can_ debug Windows programs on the source level, but only if they are compiled by GCC, either the MinGW GCC or Cygwin GCC. ___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Crash in `i frame'
From: Richard Stallman [EMAIL PROTECTED] Date: Sun, 23 Jul 2006 01:27:11 -0400 In GDB 6.4 on GNU/Linux, I did `i frame' after a strange Emacs crash involving stack clobberage. The command did not work, reporting internal error in dwarf-frame2.c:676. (I am typing this from memory; I can't be sure of the file name, but the line number was definitely 676.) The selected frame was the innermost one, and was calling __kernel_vsyscall (that may not be the precise spelling). `i frame' is a low-level command for last resort examination of the stack, in comfusing cases. It must be written defensively, so that it _always_ works, no matter how unreasonable the data is. It must never report internal error; it must do something reasonable, no matter what data it finds. Please ack when this is fixed -- it is very important. GDB 6.5 was released recently; please try that. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: `distclean' incomplete
Date: Fri, 16 Sep 2005 01:04:00 +0400 From: Ilya N. Golubev [EMAIL PROTECTED] Version: 6.3 `make distclean' leaves the following files in build directory. intl/config.h intl/config.status intl/stamp-h gdb/doc/gdb.info gdb/doc/gdb.info-1 gdb/doc/gdb.info-2 gdb/doc/gdb.info-3 gdb/doc/gdb.info-4 gdb/observer.h gdb/ada-lex.c gdb/observer.inc utils/sparclite/Makefile utils/sparclite/config.status utils/wince/config.status utils/wince/Makefile Not all of those should be removed by make distclean, IMHO: the files gdb.info*, observer.c, and ada-lex.c should stay. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: never builds gdb.info
Date: Mon, 30 May 2005 22:08:17 +0400 From: Ilya N. Golubev [EMAIL PROTECTED] CC: bug-gdb@gnu.org if `gdb.texinfo' or other `gdb.info' prerequisite was changed, will `make install' install updated `gdb.info' version? Yes, it should. The worst is that distribution does not even contain `INSTALL' file to document this, um, irregularity. The installation instructions are in README, and they do mention make info. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: gdb.info: no gdb-cfg.texi
Date: Fri, 27 May 2005 22:55:31 +0400 From: Ilya N. Golubev [EMAIL PROTECTED] Version: 6.3 Can not rebuild `gdb.info' even by explicit command. At least one required file is neither in distribution nor gets built. gdb-cfg.texi is a generated file. If you say make info, it will be built. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: never builds gdb.info
Date: Fri, 27 May 2005 22:48:46 +0400 From: Ilya N. Golubev [EMAIL PROTECTED] Version: 6.3 `make' does not even try to build `gdb.info'. ../share/gdb-6.3/configuremake rm ../share/gdb-6.3/gdb/doc/gdb.info* make ls ../share/gdb-6.3/gdb/doc/gdb.info* ls: ../share/gdb-6.3/gdb/doc/gdb.info*: No such file or directory This is by design (although personally I think it's a wrong design): you need to say make info to get the documentation built. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: [RFA] Fix file name generation in edit_command (was: Ver 6.3 edit command failing)
Date: Thu, 28 Apr 2005 17:18:03 -0400 From: Daniel Jacobowitz [EMAIL PROTECTED] Cc: bug-gdb@gnu.org, [EMAIL PROTECTED] Or using a mechanism to start other processes that takes an argument vector :-) Unfortunately, that's not a magic wand, either. Specifically, in the case in point, $EDITOR can be a _shell_command_, not a file name of a program. That is, I could say export EDITOR=emacs -q and expect it to work. This will fail with vector-argument method of invoking subprocesses. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: [RFA] Fix file name generation in edit_command (was: Ver 6.3 edit command failing)
Date: Wed, 27 Apr 2005 14:04:10 -0400
From: Daniel Jacobowitz [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], bug-gdb@gnu.org, [EMAIL PROTECTED]
It strikes me as odd that you can use edit if GDB doesn't know where
the source file is. I realize this is a pre-existing condition, but...
Also, symtab_to_fullname includes the cached fullname check. So what's
your opinion of boiling the whole thing down to:
fn = symtab_to_fullname (sal.symtab);
if (fn == NULL)
error (_(Could not find file \%s\), sal.symtab-filename);
p = xstrprintf (%s +%d %s, editor, sal.line, fn);
Mark, can I have those bonus points? :-)
I ended up committing the attached. Note that it quotes the file
name, to account for possible special characters that would confise
the shell. (I use ... for quoting because this is more portable to
various shells, including on Windows.)
Thanks to Daniel and Mark for valuable input.
2005-04-28 Eli Zaretskii [EMAIL PROTECTED]
* cli/cli-cmds.c (edit_command): If symtab-fullname is not yet
set, use symtab_to_fullname, instead of trying to do its job. Use
xstrprintf instead of malloc and sprintf.
Index: gdb/cli/cli-cmds.c
===
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- gdb/cli/cli-cmds.c 16 Mar 2005 15:58:41 - 1.58
+++ gdb/cli/cli-cmds.c 28 Apr 2005 20:32:41 - 1.59
@@ -554,7 +554,7 @@
int cmdlen, log10;
unsigned m;
char *editor;
- char *p;
+ char *p, *fn;
/* Pull in the current default source line if necessary */
if (arg == 0)
@@ -627,25 +627,26 @@
if ((editor = (char *) getenv (EDITOR)) == NULL)
editor = /bin/ex;
-
+
/* Approximate base-10 log of line to 1 unit for digit count */
for(log10=32, m=0x8000; !(sal.line m) log100; log10--, m=m1);
log10 = 1 + (int)((log10 + (0 == ((m-1) sal.line)))/3.32192809);
- cmdlen = strlen(editor) + 1
- + (NULL == sal.symtab-dirname ? 0 : strlen(sal.symtab-dirname) + 1)
-+ (NULL == sal.symtab-filename? 0 : strlen(sal.symtab-filename)+ 1)
-+ log10 + 2;
-
- p = xmalloc(cmdlen);
- sprintf(p,%s +%d %s%s,editor,sal.line,
- (NULL == sal.symtab-dirname ? ./ :
-(NULL != sal.symtab-filename *(sal.symtab-filename) != '/') ?
- sal.symtab-dirname : ),
- (NULL == sal.symtab-filename ? unknown : sal.symtab-filename)
- );
- shell_escape(p, from_tty);
+ /* If we don't already know the full absolute file name of the
+ source file, find it now. */
+ if (!sal.symtab-fullname)
+{
+ fn = symtab_to_fullname (sal.symtab);
+ if (!fn)
+ fn = unknown;
+}
+ else
+fn = sal.symtab-fullname;
+ /* Quote the file name, in case it has whitespace or other special
+ characters. */
+ p = xstrprintf (%s +%d \%s\, editor, sal.line, fn);
+ shell_escape(p, from_tty);
xfree(p);
}
___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
[RFA] Fix file name generation in edit_command (was: Ver 6.3 edit command failing)
Date: Tue, 12 Apr 2005 09:58:25 -0400
From: [EMAIL PROTECTED]
While using gdb 6.3, I was having a problem with the directory name and the
file name being concatenated by the edit command without an intervening slash.
My solution was just to add the slash to the sprintf format string
in cli/cli-cmds.c, near line 650. It worked for me.
Thanks for pointing this out.
In fact, the code there had quite a few problems besides the one you
found: it didn't use symtab-fullname, failed miserably for DOS-style
d:/foo/bar file names, etc.
Does anyone object to the following patch?
2005-04-27 Eli Zaretskii [EMAIL PROTECTED]
* cli/cli-cmds.c (edit_command): Use symtab-fullname if
possible. Use IS_ABSOLUTE_PATH instead of checking for a literal
'/'. Make sure there's a slash between the directory and the file
name. Simplify and clarify the code logic.
--- gdb/cli/cli-cmds.c~02005-03-26 16:18:14.0 +0300
+++ gdb/cli/cli-cmds.c 2005-04-27 17:14:46.0 +0300
@@ -554,7 +554,7 @@ edit_command (char *arg, int from_tty)
int cmdlen, log10;
unsigned m;
char *editor;
- char *p;
+ char *p, *fn, *dn;
/* Pull in the current default source line if necessary */
if (arg == 0)
@@ -627,23 +627,33 @@ edit_command (char *arg, int from_tty)
if ((editor = (char *) getenv (EDITOR)) == NULL)
editor = /bin/ex;
-
+
/* Approximate base-10 log of line to 1 unit for digit count */
for(log10=32, m=0x8000; !(sal.line m) log100; log10--, m=m1);
log10 = 1 + (int)((log10 + (0 == ((m-1) sal.line)))/3.32192809);
- cmdlen = strlen(editor) + 1
- + (NULL == sal.symtab-dirname ? 0 : strlen(sal.symtab-dirname) + 1)
-+ (NULL == sal.symtab-filename? 0 : strlen(sal.symtab-filename)+ 1)
-+ log10 + 2;
-
+ dn = ;
+ if (NULL != sal.symtab-fullname)
+fn = sal.symtab-fullname;
+ else if (NULL == sal.symtab-filename)
+{
+ fn = unknown;
+ if (NULL != sal.symtab-dirname)
+ dn = sal.symtab-dirname;
+}
+ else if (IS_ABSOLUTE_PATH (sal.symtab-filename))
+fn = sal.symtab-filename;
+ else
+{
+ fn = sal.symtab-filename;
+ dn = sal.symtab-dirname;
+ if (NULL == dn)
+ dn = .;
+}
+ /* $EDITOR blank +NN blankdir / file \0 */
+ cmdlen = strlen(editor) + 1 + log10 + 2 + strlen(dn) + 1 + strlen(fn) + 1;
p = xmalloc(cmdlen);
- sprintf(p,%s +%d %s%s,editor,sal.line,
- (NULL == sal.symtab-dirname ? ./ :
-(NULL != sal.symtab-filename *(sal.symtab-filename) != '/') ?
- sal.symtab-dirname : ),
- (NULL == sal.symtab-filename ? unknown : sal.symtab-filename)
- );
+ sprintf (p, %s +%d %s%s%s, editor, sal.line, dn, (*dn ? / : ), fn);
shell_escape(p, from_tty);
xfree(p);
___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: [RFA] Fix file name generation in edit_command (was: Ver 6.3 edit command failing)
Date: Wed, 27 Apr 2005 10:36:20 -0400
From: Daniel Jacobowitz [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], bug-gdb@gnu.org, [EMAIL PROTECTED]
I can simplify this a whole lot further :-)
You should use symtab_to_fullname. Then all the fallback logic is
unnecessary; if symtab_to_fullname fails, GDB does not know where the
file is.
Thanks for the tip. Here's the revised patch:
2005-04-27 Eli Zaretskii [EMAIL PROTECTED]
* cli/cli-cmds.c (edit_command): If symtab-fullname is not yet
set, use symtab_to_fullname , instead of trying to do its job.
--- gdb/cli/cli-cmds.c~02005-03-26 16:18:14.0 +0300
+++ gdb/cli/cli-cmds.c 2005-04-27 18:37:34.0 +0300
@@ -554,7 +554,7 @@ edit_command (char *arg, int from_tty)
int cmdlen, log10;
unsigned m;
char *editor;
- char *p;
+ char *p, *fn;
/* Pull in the current default source line if necessary */
if (arg == 0)
@@ -627,23 +627,26 @@ edit_command (char *arg, int from_tty)
if ((editor = (char *) getenv (EDITOR)) == NULL)
editor = /bin/ex;
-
+
/* Approximate base-10 log of line to 1 unit for digit count */
for(log10=32, m=0x8000; !(sal.line m) log100; log10--, m=m1);
log10 = 1 + (int)((log10 + (0 == ((m-1) sal.line)))/3.32192809);
- cmdlen = strlen(editor) + 1
- + (NULL == sal.symtab-dirname ? 0 : strlen(sal.symtab-dirname) + 1)
-+ (NULL == sal.symtab-filename? 0 : strlen(sal.symtab-filename)+ 1)
-+ log10 + 2;
-
+ /* If we don't already know the full absolute file name of the
+ source file, find it now. */
+ if (NULL == sal.symtab-fullname)
+{
+ fn = symtab_to_fullname (sal.symtab);
+ if (NULL == fn)
+ fn = unknown;
+}
+ else
+fn = sal.symtab-fullname;
+
+ /* $EDITOR blank +NN blankfile \0 */
+ cmdlen = strlen(editor) + 1 + log10 + 2 + strlen(fn) + 1;
p = xmalloc(cmdlen);
- sprintf(p,%s +%d %s%s,editor,sal.line,
- (NULL == sal.symtab-dirname ? ./ :
-(NULL != sal.symtab-filename *(sal.symtab-filename) != '/') ?
- sal.symtab-dirname : ),
- (NULL == sal.symtab-filename ? unknown : sal.symtab-filename)
- );
+ sprintf (p, %s +%d %s, editor, sal.line, fn);
shell_escape(p, from_tty);
xfree(p);
___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 6.1 blues
From: Nikos Balkanas [EMAIL PROTECTED] Date: Mon, 21 Mar 2005 04:42:19 +0200 Problem: (1) Source lines get messed up (2) Just evaluated variables, are out of context (may be previous problem) These all happen because of the compiler optimizations (the -O2 switch to GCC): auth.o: auth.c gcc -g -O2 -Wall -I../include/ -c -o auth.o auth.c The optimizer rearranges code so that a single source line may be split between several different code locations, that's why stepping in GDB appears to execute a line several times. Btw, it's better to use -ggdb3 instead of -g, as that might give GDB better debug info and help it help you during debugging. These 2 problems render gdb unusuable and I have to resort on printfs for debugging. If you did this because you don't believe the debugger is showing you the truth, then believe it, and use one of the 2 techniques below. First, you can always compile without optimizations. But that has a disadvantage that you will be debugging a very different program than you will later use in production, so I recommend this only as the last resort. To debug an optimized program, you need to step through the code until the source line you are interested in is no longer shown. For example, in this case: $ gdb nbssh b ssh_userauth_kbdint r 127.0.0.1 Breakpoint 1 file auth.c: function ssh_userauth_kbdint ... int err = 0; n int ssh_userautrh_kbdint(SESSION *session ...) n if (!username) type n a few more times, and you will see that the same few first lines of the function are shown time and again. Wait until you get to the line after if (!username), and then you can be sure that the code produced by the first few lines of the function was executed in its entirety, and the `err' variable's value can then be printed. As for this: p err variable err not available the optimizer could sometimes optimize a variable out of existence, or put it into a register. So get used to the commands info address and info locals to find out which local variables are stored where. Here, too, while you are still in the function's prologue, GDB might say that a variable is not in the current context, so step a while into the function and try again. Debugging an optimized program like this takes used to, but it is certainly doable, and the advantage is that you are debugging teh same code you (or your clients) will be using in production. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
From: Francesco Potorti` [EMAIL PROTECTED] Date: Sat, 26 Jan 2002 17:22:23 +0100 As far as I can tell, the backtrace of gdb's core looks like the backtrace of a dumped Emacs, but it is different from the real backtrace of the Emacs that was being debugged. Sorry, I don't understand what do you mean. Can you show the GDB backtrace from this crash? Maybe that's normal, I don't have any idea of what should a crashed gdb's backtrace look like. It should show functions which appear in GDB sources, not the ones in Emacs sources ;-) ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
From: Francesco Potorti` [EMAIL PROTECTED] Date: Tue, 22 Jan 2002 12:27:11 +0100 (gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) Does GDB's core file say something interesting about where did GDB crash? Anyway, since no one responded, let me rephrase the (implicit) question in Francesco's report: Is GDB supposed to handle invalid memory accesses gracefully? That is, if the user asks GDB to access the inferior's memory via an invalid pointer, does GDB protect itself against SIGSEGV and other related calamities? ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
