<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - unfriendly error message when debugee does not start correctly"
   href="https://bugs.llvm.org/show_bug.cgi?id=48723">48723</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>unfriendly error message when debugee does not start correctly
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>lldb
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>FreeBSD
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>All Bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>lldb-dev@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>emaste@freebsd.org
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>jdevlieghere@apple.com, llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>On FreeBSD, and I assume other operating systems, there are cases where the
debugged application does not start correctly.

One recent case occurred on FreeBSD with W^X enabled (sysctl
kern.elf64.allow_wx=0) and an attempt to execute a binary that requested an
executable stack. Because W^X disallows mappings with simultaneous W & X
protections the initial stack cannot be created and the kernel image activator
reports SIGABRT from the target.

Similar cases occurred when attempting to execute a binary with a .text segment
larger than a kernel limit.

The failure reported by LLDB in this case is not particularly clear:

$ lldb ./exec-stack
(lldb) target create "./exec-stack"
Current executable set to
'/home/emaste/src/freebsd-git/main/exec-stack' (x86_64).
(lldb) run
error: 'A' packet returned an error: 8


The old in-process target plugin handled this even more poorly:

(lldb) run
Assertion failed: (WIFSTOPPED(status) && wpid == (::pid_t)pid &&
"Could not sync with inferior process."), function Launch, file
/usr/home/emaste/src/freebsd-git/head/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp,
line 930.
PLEASE submit a bug report to <a href="https://bugs.freebsd.org/submit/">https://bugs.freebsd.org/submit/</a> and
include the crash backtrace.
#0 0x0000000004444ade PrintStackTrace
/usr/home/emaste/src/freebsd-git/head/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#1 0x0000000004442e11 RunSignalHandlers
/usr/home/emaste/src/freebsd-git/head/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18
#2 0x0000000004445335 SignalHandler
/usr/home/emaste/src/freebsd-git/head/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
#3 0x0000000805299b20 handle_signal
/usr/home/emaste/src/freebsd-git/head/lib/libthr/thread/thr_sig.c:0:3
Abort trap (core dumped)

Although a relatively minor issue it would be nice to have an error message
along the lines of "Unable to start inferior process" or such. Taking this to
root cause would likely require finding a log message in the kernel log.

(For reference, the FreeBSD code review that prompted this investigation:
<a href="https://reviews.freebsd.org/D28050">https://reviews.freebsd.org/D28050</a>)</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>