[Lldb-commits] [PATCH] D30817: BreakpointResolverFileLine: Correct treatment of move-to-nearest-code for multiple modules

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Mar 15 02:58:09 PDT 2017


labath marked an inline comment as done.
labath added a comment.

In https://reviews.llvm.org/D30817#700825, @jingham wrote:

> This seems good to me.  Thanks for doing this.
>
> I made a few inline comments, but none are serious.
>
> Maybe I'm a little over-cautious about this sort of thing, but GetStartLineSourceInfo will return the first line in the line table if there is no decl_file & decl_line.  I prefer to only do this if we had decl_file and decl_line, since we know that the fudge factor will be too small for the case where the function beginning is really the first line table entry.


I tried to to this as conservatively as possible. E.g. if I compile the binary with `-gline-tables-only` then `sc.function` will be null and we will not do any filtering. I guess we could arrive in this situation if the compiler chooses to not emit `DW_AT_decl_line` attributes, even though the rest of the DWARF is present, but I think at that point the user will have bigger problems than his breakpoints not being flexible enough.



================
Comment at: packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/foo.h:1-4
+LLDB_TEST_API inline int foo1() { return 1; } // !BR1
+
+LLDB_TEST_API inline int foo2() { return 2; } // !BR2
+
----------------
jingham wrote:
> At other places in the testsuite we use something like:
> 
> 
> ```
> #define INLINE inline __attribute__((always_inline))
> 
> ```
> to force inlining if we intend it.  IIRC inline is just advisory.
> 
> 
I don't need or want to force inlining for this test. What I need is make sure the compiler does not emit code for the function if it is not used in the compilation unit. I suppose inline doesn't guarantee that, but neither does always_inline. I guess if some days compilers start emitting code for all functions, we'll need to update the test, but I doubt that's going to happen, as that would make intermediate files huge.


https://reviews.llvm.org/D30817





More information about the lldb-commits mailing list