Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lldb] Inconsistent Order of messages in process launch behaviour #68035

Closed
junior-jl opened this issue Oct 2, 2023 · 2 comments · Fixed by #73173
Closed

[lldb] Inconsistent Order of messages in process launch behaviour #68035

junior-jl opened this issue Oct 2, 2023 · 2 comments · Fixed by #73173
Labels

Comments

@junior-jl
Copy link
Contributor

Issue Description:
When using the process launch command in LLDB with a previously created breakpoint, there is an inconsistency in the order of messages displayed in the debugger prompt. Depending on how the command is executed, the "Process launched" message may appear either before or after the "Process stopped" message.

Steps to Reproduce:
Execute LLDB with the following command: $ path/to/llvm-project/bin/lldb /path/to/executable -o "b main" -o "r"

The "Process X launched" message is displayed after the "Process X stopped" message.

This does not happen if the commands are passed in the (lldb) prompts.

Example:

$ ./bin/lldb ~/main.out -o 'b main' -o 'r'
(lldb) target create "/home/jose/main.out"
Current executable set to '/home/jose/main.out' (x86_64).
(lldb) b main
Breakpoint 1: where = main.out`main + 15 at main.c:2:21, address = 0x000000000000114f
(lldb) r
Process 67805 stopped
* thread #1, name = 'main.out', stop reason = breakpoint 1.1
    frame #0: 0x000055555555514f main.out`main at main.c:2:21
   1   	int foo() { return 0; }
-> 2   	int main() { return foo(); }
   3
Process 67805 launched: '/home/jose/main.out' (x86_64)
(lldb) 

Expected output:

$ ./bin/lldb ~/main.out
(lldb) target create "/home/jose/main.out"
Current executable set to '/home/jose/main.out' (x86_64).
(lldb) b main
Breakpoint 1: where = main.out`main + 15 at main.c:2:21, address = 0x000000000000114f
(lldb) r
Process 67920 launched: '/home/jose/main.out' (x86_64)
Process 67920 stopped
* thread #1, name = 'main.out', stop reason = breakpoint 1.1
    frame #0: 0x000055555555514f main.out`main at main.c:2:21
   1   	int foo() { return 0; }
-> 2   	int main() { return foo(); }
   3

Related Context:

  • This issue was discussed in a related PR, which implements an option to process launch that launches the process and pauses execution in the entry point of the program, and it was suggested that this behavior should be addressed separately.
@llvmbot
Copy link
Collaborator

llvmbot commented Oct 2, 2023

@llvm/issue-subscribers-lldb

**Issue Description:** When using the `process launch` command in LLDB with a previously created breakpoint, there is an inconsistency in the order of messages displayed in the debugger prompt. Depending on how the command is executed, the "Process launched" message may appear either before or after the "Process stopped" message.

Steps to Reproduce:
Execute LLDB with the following command: $ path/to/llvm-project/bin/lldb /path/to/executable -o "b main" -o "r"

The "Process X launched" message is displayed after the "Process X stopped" message.

This does not happen if the commands are passed in the (lldb) prompts.

Example:

$ ./bin/lldb ~/main.out -o 'b main' -o 'r'
(lldb) target create "/home/jose/main.out"
Current executable set to '/home/jose/main.out' (x86_64).
(lldb) b main
Breakpoint 1: where = main.out`main + 15 at main.c:2:21, address = 0x000000000000114f
(lldb) r
Process 67805 stopped
* thread #<!-- -->1, name = 'main.out', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x000055555555514f main.out`main at main.c:2:21
   1   	int foo() { return 0; }
-&gt; 2   	int main() { return foo(); }
   3
Process 67805 launched: '/home/jose/main.out' (x86_64)
(lldb) 

Expected output:

$ ./bin/lldb ~/main.out
(lldb) target create "/home/jose/main.out"
Current executable set to '/home/jose/main.out' (x86_64).
(lldb) b main
Breakpoint 1: where = main.out`main + 15 at main.c:2:21, address = 0x000000000000114f
(lldb) r
Process 67920 launched: '/home/jose/main.out' (x86_64)
Process 67920 stopped
* thread #<!-- -->1, name = 'main.out', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x000055555555514f main.out`main at main.c:2:21
   1   	int foo() { return 0; }
-&gt; 2   	int main() { return foo(); }
   3

Related Context:

  • This issue was discussed in a related PR, which implements an option to process launch that launches the process and pauses execution in the entry point of the program, and it was suggested that this behavior should be addressed separately.

@junior-jl
Copy link
Contributor Author

While debugging two sessions of process launch -m (one interactive and the other non-interactive), I noticed divergent behaviour between them.

  • The potential reason why 'Process X stopped' was being printed before 'Process X launched' is in source/Commands/CommandObjectProcess.cpp::ComandObjectProcessLaunch::DoExecute:
if (process_sp) {
        ...
        llvm::StringRef data = stream.GetString();
        if (!data.empty())
          result.AppendMessage(data);
        ...
        result.SetStatus(eReturnStatusSuccessFinishResult);
        ...

By moving

if (!data.empty())
          result.AppendMessage(data);

to the point before result.SetStatus(eReturnStatusSuccessFinishResult); the issue was solved. However, while the tests passed, I'm not sure if this alteration could introduce other problems.

$ lldb ~/a.out -o 'process launch -m' -o 'exit'
(lldb) target create "/home/jose/a.out"
Current executable set to '/home/jose/a.out' (x86_64).
(lldb) process launch -m
Process 16818 launched: '/home/jose/a.out' (x86_64)
Process 16818 stopped
* thread #1, name = 'a.out', stop reason = one-shot breakpoint 1
    frame #0: 0x00005555555551c0 a.out`main at a.cpp:9
   6   	}
   7   	
   8   	int main()
-> 9   	{
   10  		int a = 3;
   11  		int x = 5 + a;
   12  		int j;
(lldb) exit

I actually realized this some time ago, but there was another problem I was trying to tackle:

  • When the source code had something to be ran before main:
$ lldb ~/s.out -o 'process launch -m' -o 'exit'
(lldb) target create "/home/jose/s.out"
Current executable set to '/home/jose/s.out' (x86_64).
(lldb) process launch -m
Initialization code running before main()
Process 17755 launched: '/home/jose/s.out' (x86_64)
Process 17755 stopped
* thread #1, name = 's.out', stop reason = one-shot breakpoint 1
    frame #0: 0x0000555555555160 s.out`main at s.c:10
   7   	    printf("Initialization code running before main()\n");
   8   	}
   9   	
-> 10  	int main() {
   11  	    printf("This is the main function\n");
   12  	    return 0;
   13  	}
(lldb) exit

I'm not sure if this is expected. The execution of both cases diverge in source/Target/Target.cpp::Launch:

if (synchronous_execution)
      ...
      m_process_sp->ResumeSynchronous(stream);
    else
      error = m_process_sp->Resume();

The non-interactive execution has synchronous_execution = true;
The interactive execution has synchronous_execution = false.

I must admit, I found this section of the source code a bit challenging to fully comprehend. Any insights?

DavidSpickett pushed a commit that referenced this issue Nov 24, 2023
Fixes [#68035](#68035), where
an inconsistency in the order of "Process launched" and "Process
stopped" messages occurs during `process launch`.

The fix involves adjusting the message output sequence in
`CommandObjectProcessLaunch::DoExecute` within
`source/Commands/CommandObjectProcess.cpp`. This ensures "Process
launched" consistently precedes "Process stopped" when executing
commands with the '-o' flag, i.e., non-interactive mode.

Upon implementing this change, two tests failed:
`lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test` and
`lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test`. These failures
were expected as they relied on the previous, now-corrected message
order. Updating these tests to align with the new message sequence is
part of this PR's scope.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants