Missing/wrong build dependencies for inline functions in HotSpot

[Keith McGuigan]

I don't understand why gcc doesn't put frame_x86.inline.hpp into the 
generated/dependencies/frame.o.d file.  Isn't the point of -MMD to 
calculate the full closer of header files used for listing as a 
dependency?  Is this a bug in gcc or are we using it wrong?

I notice that Sun Studio compiler does put the arch-specific header file 
in the generated dependency file.  Weird.

--
- Keith

On 6/8/2012 11:58 AM, Volker Simonis wrote:
> Hi,
>
> I've just stumbled across the problem that changing the implementation
> of an inline function in HotSpot does not necessarily rebuild all the
> call sites of that function. This is because because of the way how
> the build dependencies are handled within the HotSpot. As an example
> you may have a look at frame.cpp:
>
> frame.cpp includes frame.inline.hpp
> frame.inline.hpp includes frame_x86.inline.hpp
>
> However frame.cpp only depends on frame.inline.hpp directly (i.e.
> frame.cpp only includes frame.inline.hpp directly and this is where
> the dependencies generated by gcc with '-MMD' are computed from).
> So if an inline function in frame_x86.inline.hpp will be changed (e.g.
> the constructor frame::frame()), frame.cpp will not be recompiled in
> an incremental build, although it uses the constructor frame::frame().
> This makes incremental builds useless (or dangerous, depending on the
> view point) when inline functions are changed.
>
> I think this is a non-trivial problem which is deeply rooted in the
> way how C++ implements inlining and the way how inline functions are
> defined in HotSpot (i.e. .hpp, .inline.hpp,  _<cpu>.hpp and
> _<cpu>.inline.hpp files). I don't have a solution for it but just
> wanted to ask if somebody else already stumbled upon this problem
> and/or has solution for it?
>
> Regards,
> Volker