<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 14/02/2014 01:36, Xiangrong Fang
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP93jB1EstbpY2bt-C=2nPrXxvQMKCoLtWvtWiwH1MEY9GfbXw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:courier
          new,monospace">Hi Martin,</div>
        <div class="gmail_default" style="font-family:courier
          new,monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:courier
          new,monospace">
          <span style="font-family:arial">2014-02-14 1:14 GMT+08:00
            Martin Frb </span><span dir="ltr" style="font-family:arial"><<a
              moz-do-not-send="true" href="mailto:lazarus@mfriebe.de"
              target="_blank">lazarus@mfriebe.de</a>></span><span
            style="font-family:arial">:</span><br>
        </div>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div class="">
                  <div>With -O2 and above the debugger does not always
                    work.<br>
                  </div>
                </div>
                <br>
                In case of such optimization the debug info compiled
                into the exe by fpc is not always accurate.<br>
                <br>
                It is not just blue dots, inspecting variables may show
                random data, ....<br>
                <br>
                Debugging with O2 and up, if you must, requires to only
                look at the disassembler and register window. registers
                can only be trusted in the ttop stackframe. selecting
                any other may not show correct info. <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div class="gmail_default" style="font-family:'courier
              new',monospace">I never use optimization option other than
              O1, I think O1 is the default.  As Sven suggested, I tried
              turning off optimization, and back on, still at O1 level.</div>
            <div class="gmail_default" style="font-family:'courier
              new',monospace">​​<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sorry, then I misunderstood you.<br>
    <br>
    So where the blue dots missing, while you where at -O-? Or where
    they missing at -O1, and after you went to -O-, compiled (run), and
    went back to -O-1 they came back?<br>
    <br>
    In either case, they should be there with -O- and -O1 , so if that
    is all you changed, then maybe it needed a clean build, and by
    changing settings, you triggered this clean build.<br>
    <br>
    ---<br>
    Strange though, because without blue dots, normally breakpoints to
    not work, but yours did (on the wrong line, but it did break).<br>
    <br>
    The only other thing I can think of is, if you have symlinks to your
    files, and did open them in the IDE via different links/original.
    And/or fpc used a different symlink than the IDE.<br>
    <br>
    In that cases it can happen that the IDE believes you have 2
    independent files, while really you got just one. However
    breakpoints will work, because the error gets corrected when the IDE
    gives the wrong path to gdb, and retries with filename (no path)
    only. then gdb will set the breakpoint.<br>
    <br>
  </body>
</html>