That looks like it sort of solved it, as in the instrumentation function
call is recognized. I am getting a problem at the linking stage though
(errors below):
First off, I am building for arm: make -j 2 arm.release. So I am not sure
why the Linux_x64 release is showing up. The main error though about
__cxa_demangle
could be solved with an extern C {} type declaration right?
I included the library header file in the v8 source code:
#include "/home/musleh/Research/gem5-ARM/util/m5/m5op.h"
and added the following to v78.gyp:
'conditions': [
['nacl_target_arch=="none"', {
'link_settings': {
'libraries': [
+ '/home/musleh/Research/gem5-ARM/util/m5/libm5.a -lrt'
],
},
}, {
and similarly under include_dir:
'include_dirs': [
'../..', '/home/musleh/Research/gem5-ARM/util/m5',
],
any idea as to if I am missing something else?
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/third_party/binutils/Linux_x64/Release/bin/ld.gold: the
vtable symbol may be undefined because the class is missing its key function
/home/musleh/v8/out/arm.release/obj.host/tools/gyp/libv8_libbase.a(/home/musleh/v8/out/arm.release/obj.host/v8_libbase/src/base/logging.o):../src/base/logging.cc:function
v8::base::DumpBacktrace(): error: undefined reference to '__cxa_demangle'
/home/musleh/v8/out/arm.release/obj.host/tools/gyp/libv8_libbase.a(/home/musleh/v8/out/arm.release/obj.host/v8_libbase/src/base/platform/platform-linux.o):../src/base/platform/platform-linux.cc:function
void std::vector<v8::base::OS::SharedLibraryAddress,
std::allocator<v8::base::OS::SharedLibraryAddress>
>::_M_insert_aux<v8::base::OS::SharedLibraryAddress>(__gnu_cxx::__normal_iterator<v8::base::OS::SharedLibraryAddress*,
>
std::vector<v8::base::OS::SharedLibraryAddress,
std::allocator<v8::base::OS::SharedLibraryAddress> > >,
v8::base::OS::SharedLibraryAddress&&): error: undefined reference to
'std::string::swap(std::string&)'
/home/musleh/v8/out/arm.release/obj.host/tools/gyp/libv8_libbase.a(/home/musleh/v8/out/arm.release/obj.host/v8_libbase/src/base/platform/platform-linux.o):../src/base/platform/platform-linux.cc:function
void std::vector<v8::base::OS::SharedLibraryAddress,
std::allocator<v8::base::OS::SharedLibraryAddress>
>::_M_insert_aux<v8::base::OS::SharedLibraryAddress>(__gnu_cxx::__normal_iterator<v8::base::OS::SharedLibraryAddress*,
>
std::vector<v8::base::OS::SharedLibraryAddress,
std::allocator<v8::base::OS::SharedLibraryAddress> > >,
v8::base::OS::SharedLibraryAddress&&): error: undefined reference to
'std::string::swap(std::string&)'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
make[1]: *** [/home/musleh/v8/out/arm.release/mksnapshot] Error 1
make[1]: Leaving directory `/home/musleh/v8/out'
On Wednesday, February 25, 2015 at 4:18:32 AM UTC-5, Ben Noordhuis wrote:
>
> On Wed, Feb 25, 2015 at 5:20 AM, Malek Musleh <[email protected]
> <javascript:>> wrote:
> > Hi,
> >
> > I am trying to instrument the v8 source code with callable functions
> defined
> > in a separate (external library).
> > Specifically, I am inserting these instrumentation function calls in
> > ./src/ic/arm/ic-arm.cc
> >
> > Is the main Makefile (v8/Makefile) the best place to include a link
> against
> > my external library or is there a more formal
> > way of doing so?
> >
> > I have access to the source code of the external library, so
> theoretically I
> > could include the library source files within the v8 build structure,
> > but from past experiences, it would seem this would be the undesirable
> > approach.
> >
> > Malek
>
> I think you should be able to add it to the 'libraries' element in the
> appropriate 'link_settings' section in tools/gyp/v8.gyp. You will
> probably also need to update one of the 'include_dirs' elements if the
> external library comes with its own headers.
>
> If you are going to integrate V8 with a downstream project that also
> builds with GYP, you should also update the appropriate
> 'direct_dependent_settings' section to make downstream pick up the
> required link settings automatically.
>
--
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
