termination of options in the ladebug command

[Noack_1]

Hello,
I work on TRU64 and want to start the ladebug with the following command

%ladebug myprog.out -myoption

where -myoption ist a option for myprog.out .

In the above command ladebug reads -myoption and terminates with the error message

unrecognized option: -myoption
Usage:
ladebug [-c file ] [-emacs] ...

Please can anyone point me to the solution where I can prevent that ladebug reads -myoption.

Thank you in advance.
dino

[Michael Schulte zur Sur]

Hi,

according to man ladebug:
-P Specifies the arguments used by the program you are debugging.

greetings,

Michael

[Ralf Puchner]

use:

# ladebug myprg
(ladebug) run -myoption

PS: -P doesn't work with all versions of ladebug.

[Noack_1]

Hi all,

I use Ladebug Debugger Version 66 and I cannot find an option -P in the man ladebug.

Further, the problem is a little more complex. Since the command is generated by a binary module for which I have no source, I cannot change -myoption. The command should be used in the following form

myprog.out -myoption ...

But it is only permitted to add a prefix to the command. Since I want to debug myprog I add the prefix ladebug and get

ladebug myprog.out -myoption

So I thought I should use a terminator for the options, i.e. "--" to define that -myoption is part of myprog. Is there somewhat available?

regards,
dino

[Ralf Puchner]

no, but another way is to start the program and attach ladebug via -pid option to the running process.

[Michael Schulte zur Sur]

Hi,

what about Ralf's suggestion with the run command from within ladebug?

Michael

[Noack_1]

Hi all,

thank you for your suggestions, but its all not possible.

I use a scientific program for structure analysis which was started with a command. The program than generates a script and processes the script. So I have no chance to edit the script. It is allowed to add a prefix to the command, thats all. The script runs several programs sequentielly, i.e. a preprocessor, the main programm, ..., so I have also no chance to attach the running process.

Imho, the only way is to terminate the reading of options in the ladebug command. In unix it is common to terminate the options with "--". Why does this not work for ladebug e.g.

ladebug -- myprog.out -myoption

regards,
dino

[Michael Schulte zur Sur]

Hi,

it's not that easy. What the shell is concerned, who starts ladebug, everything after ladebug are parameters for ladebug. So who should feed the programme to debug with the parameters?

Do you know in advance the names of the scripts and their location and do they remain after execution or are they deleted?

greetings,

Michael

[Noack_1]

Hi,

when the execution starts, a working directory becomes created in a random place and when the job terminates the result files are copied in the user directory and then the working directory gets deleted.

regards,
dino

[Michael Schulte zur Sur]

Hi,

Why do you need to debug it?

Michael

[Ralf Puchner]

why not replacing the second executable by a script? In this case implement a script which shows the directory and command line followed by a key input.

So if the script will be started you know the directory, the commandline. Now you can start the ladebug with the real program and parameters.

Life could be so easy....

[Noack_1]

Hi Michael,

I use a structural mechanics program. This program can be extended by user subroutines to fit for the users need. As usual the program is licensed for binary version. I have implemented several fortran subroutines (more than 3000 lines). When the program starts, it generates a script, compiles and links the user routines with the main program by using some librarys etc. Earlier I have the chance to debug my routines, if I compile my routines with option -g and use a prefix ladebug to call the ladebug. Now in a new version the command were changed and I have some trouble with the additional options. As an example for the prefix the program developer uses the time command i.e.

time myprog.out -myoption

This functions properly, but the ladebug command doesnt.

regards,
dino

[Noack_1]

Hi Ralf,

I cannot replace the second executable with a script. Since the program generates automatically a script that compiles, links, runs and deletes itself, I have no chance to edit the script and replace the second executable.

regards,
dino

[Ralf Puchner]

how about the idea of attaching to the process via ladebug -pid during runtime?

[Noack_1]

Hi Ralf,
I have to debug my routines from the first entry to check for formal parameters etc. Therefore attaching the runnning process is probably to late. The program crashes before I have determined the pid and attached the process.

I think the only solution for my problem is debugging manually with write-statements in my routines.

regards,
dino

[Ralf Puchner]

if application cores, why not analyzing core?

[Noack_1]

The program solves a system of ordinary differential equations. This involves a huge number of integration steps. If the program cores, it is to late for analysing it by debugging.

On the other hand I would also like to debug the program to verify the program flow.

[Michael Schulte zur Sur]

Hi,

Can you replace the compiler command with a script, that does the compiling, linking and then start the ladebug?
You still did not comment on Ralfs suggestion to supply the parameters for the programme via run.

Michael

[Ralf Puchner]

A core is a memory dump of the application during runtime, so the root cause of the problem will be included and also all memory informations of the process. If you don't know how to analyze a core let us know.

Maybe if using the trace utility you will get closer informations during startup and runtime (if it is not a multithreading application). Maybe this will solve some mystics problems without deeper knowledge of debugging....

[Noack_1]

OK, thank you all for your suggestions. In the meantime I have found a work around, that fits my needs.

I start the program with the prefix ladebug #. The script generates symbols, directories, options etc. and so I get

dxladebug # myprog.out -myoption ...

If the script reaches this command, dxladebug starts its GUI and waits for input. At this time I am in the place of the working directory. Now I can examine the log-file and cut and paste the executable, options and parameters in the GUI and set a breakpoint. Finally I click on run and I can debug my routines, see the source and all works fine.

It is a little long winded, but obviously there isnt another a smart solution available, like "--" or -exec{...}.

regards,
dino