[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-cflow] cflow-1.1 doesn't find main
From: |
Robert E. Michael |
Subject: |
Re: [Bug-cflow] cflow-1.1 doesn't find main |
Date: |
Sat, 09 Sep 2006 15:38:44 -0400 |
Sergey,
#define program_name program_invocation_name
is already in my config.h file. That is why when I stop at line 275
and try to print program_name, gdb replies:
No symbol "program_name" in current context
But when I print program_invocation_name, gdb replies:
$10 = 0x0
So program_invocation_name is defined, but it is set to NULL,
rather than the actual program name or the value of argv[0].
So, no, it does not fix the core dump from cflow. In fact, as far
as I can tell (in argp-parse.c line 947), program_invocation_name
is only set if I set it when I execute cflow, as in:
cflow --program-name cflow c.c
That works, and I get the name I supply printed in the error
messages.
There is another curiosity that I am having trouble explaining.
In the nohup output from ./configure --enable-debug, I find the
following statements:
checking whether program_invocation_name is declared... no
checking whether program_invocation_short_name is declared... no
But in the config.h file,
HAVE_DECL_PROGRAM_INVOCATION_NAME is defined to 1,
while HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
is defined to 0. When I write a two line program that has the statements:
extern char *program_invocation_name;
printf(%s\n",program_invocation_name);
and compile it with gcc, the linker complains that
"program_invocation_name is undefined. Thus the output from the
configure script is correct, but the config.h variable
HAVE_DECL_PROGRAM_INVOCATION_NAME is set anyway.
Perhaps that is because program_invocation_name is always defined
in pin.c. But shouldn't there be some code somewhere that sets
program_invocation_name to the contents of argv[0]? Otherwise,
a user who does not supply a command line --program-name,
and whose C file or files has an error will get a core dump rather
than an error message. There is some code in argp-parse.c between
lines 556 and 569 that tries to look at argv[0], but it does not set
program_invocation_name. Instead it sets parser->state.name,
which is not used anywhere. And there is a comment around line
1689 in argp-help.c that suggests that something is broken in
this whole mess about getting a printable program name. Since
always including the variable "program_invocation_name" is
already a kludge, then its definition in pin.c should be:
char *program_invocation_name = "cflow";
That way, error messages will not cause a segmentation fault,
and the user can still supply a program name with the command
line --program-name option.
Bob Michael
Sergey Poznyakoff wrote:
> Robert E. Michael <address@hidden> wrote:
>
> > So there
> > seems to be something wrong with the definition of _LIBC, such
> > that it allows the alias of program_name to program_invocation_name,
> > but somehow program_invocation_name is never set.
>
> In fact, _LIBC is never defined, so this part of code is not
> compiled. What happens is that program_invocation_name *is* set
> (lib/argp-pin.c), whereas program_name is not. The define you are
> talking about was designed to compensate for it in case of glibc code,
> but it has no force otherwise. That is why placing `#define
> program_name program_invocation_name' in your config.h should fix it.
> Actually, that should have been done by configure, but somehow I
> forgotten to make it there:)
>
> > If I place "if (program_name != NULL)" before line 275 and
> > recompile, then cflow runs and generates dozens of "redefined"
> > error messages. I am not sure I understand enough about the
> > details of how cflow handles compiler variables like __STDC__
> > and __cplusplus.
>
> Yes, this is described in detail in the documentation (chapter 8,
> "Running Preprocessor". The online copy available at
> http://www.gnu.org/software/cflow/manual). Run it with preprocessor and
> the messages will go away. E.g.:
>
> $ cd cflow-1.1/src
> $ cflow -I.. -I. c.c
>
> Regards,
> Sergey
>
- [Bug-cflow] cflow-1.1 doesn't find main, Robert E. Michael, 2006/09/07
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Sergey Poznyakoff, 2006/09/07
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Robert E. Michael, 2006/09/08
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Robert E. Michael, 2006/09/08
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Sergey Poznyakoff, 2006/09/08
- Re: [Bug-cflow] cflow-1.1 doesn't find main,
Robert E. Michael <=
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Sergey Poznyakoff, 2006/09/10
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Robert E. Michael, 2006/09/11
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Robert E. Michael, 2006/09/11
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Sergey Poznyakoff, 2006/09/11
- Re: [Bug-cflow] cflow-1.1 doesn't find main, Sergey Poznyakoff, 2006/09/11