Re: [Bug-cflow] cflow-1.1 doesn't find main

[Robert E. Michael]

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
>