Hi John
You mean I need hide to the symbal operator new in libc.so ?
So I trip the libc.so , so there is no symbals operator new in libc.so
localhost:/system/bin # readelf -s ../lib64/libc++.so | grep Znam
696: 000000000005cd20 44 FUNC WEAK DEFAULT 12 _ZnamRKSt9nothrow_t
746: 000000000005ce34 4 FUNC WEAK DEFAULT 12 _ZnamSt11align_val_t
1793: 000000000005ce38 44 FUNC WEAK DEFAULT 12
_ZnamSt11align_val_tRKSt9
2089: 000000000005cd1c 4 FUNC WEAK DEFAULT 12 _Znam
4468: 000000000005cd1c 4 FUNC WEAK DEFAULT 12 _Znam
4778: 000000000005cd20 44 FUNC WEAK DEFAULT 12 _ZnamRKSt9nothrow_t
4779: 000000000005ce34 4 FUNC WEAK DEFAULT 12 _ZnamSt11align_val_t
4780: 000000000005ce38 44 FUNC WEAK DEFAULT 12
_ZnamSt11align_val_tRKSt9
localhost:/system/bin # readelf -s ../lib64/libc.so | grep Znam
So I re-run it , there is no printf for "REDIR to operator new " or "
malloc";
--9071-- REDIR: 0x4b23130 (libc.so:memset) redirected to 0x4c8b2b4 (memset)
--9071-- REDIR: 0x4b6a580 (libc.so:__memcpy_chk) redirected to 0x4c8ba1c
(__memcpy_chk)
--9071-- REDIR: 0x4b1fcec (libc.so:malloc) redirected to 0x4c8c168 (malloc)
--9071-- REDIR: 0x4b23710 (libc.so:strlen) redirected to 0x4c8a75c (strlen)
--9071-- REDIR: 0x4b6a514 (libc.so:__strcpy_chk) redirected to 0x4c8b7ac
(__strcpy_chk)
--9071-- REDIR: 0x4b2389c (libc.so:strncmp) redirected to 0x4c8a988 (strncmp)
--9071-- REDIR: 0x4b22c70 (libc.so:memcpy) redirected to 0x4c8adc8 (memcpy)
--9071-- REDIR: 0x4b22ab4 (libc.so:memchr) redirected to 0x4c8ab94 (memchr)
--9071-- REDIR: 0x4b1ff38 (libc.so:realloc) redirected to 0x4c8d734 (realloc)
--9071-- REDIR: 0x4b1fbac (libc.so:free) redirected to 0x4c8cdac (free)
--9071-- REDIR: 0x4b22bc0 (libc.so:memcmp) redirected to 0x4c8b02c (bcmp)
--9071-- REDIR: 0x4b23540 (libc.so:strcmp) redirected to 0x4c8ab54 (strcmp)
--9071-- REDIR: 0x4ba8620 (libc.so:strstr) redirected to 0x4c8bbe8 (strstr)
no=0x4ea4d20 n1=0x4ea4d70
--9071-- REDIR: 0x4d03a60 (libc++.so:operator delete[](void*)) redirected to
0x4c8d3c4 (operator delete[](void*))
==9071== Mismatched free() / delete / delete []
==9071== at 0x4C8D44C: operator delete[](void*) (vg_replace_malloc.c:620)
==9071== by 0x108797: demoNew (testNew.cpp:16)
==9071== by 0x108797: main (testNew.cpp:21)
==9071== Address 0x4ea4d70 is 0 bytes inside a block of size 8 alloc'd
==9071== at 0x4C8C1F0: malloc (vg_replace_malloc.c:298)
==9071== by 0x4D15CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)
==9071== by 0x10876F: demoNew (testNew.cpp:13)
==9071== by 0x10876F: main (testNew.cpp:21)
Libc++.so is llvm c++, not gnu c++;
Br
Owen
-----邮件原件-----
发件人: John Reiser [mailto:jrei...@bitwagon.com]
发送时间: 2018年4月13日 7:27
收件人: valgrind-users@lists.sourceforge.net
主题: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android
version(arm32), I am confused by function stack. Can you show me why?
> #include <stdio.h>
> #include <stdlib.h>
>
> class Node{
> public:
> int a;
> int b;
> };
>
> extern "C" void demoNew(void) {
> Node *n0 = new Node;
> Node *n1 = (Node *)new char[sizeof(Node)];
> printf("no=%p n1=%p\n", n0, n1);
> delete n0;
> delete[] n1;
> }
>
>
> int main(int argc, char ** argv) {
> demoNew();
> return 0;
> }
> --4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long))
> redirected to 0x4c1bb48 (operator new[](unsigned long))
> --4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long))
> redirected to 0x4c1b7a4 (operator new(unsigned long))
Well, it is puzzling why 'operator new[]' and 'operator new' are in libc.so,
the run-time library for *plain*-C. The C language does not have such
functions.
> --4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*))
> redirected to 0x4c1c3c4 (operator delete[](void*))
OK, that's the regular 'operator delete[]' for C++.
Where is 'operator delete', the non-array flavor?
> ==4747== Mismatched free() / delete / delete []
> ==4747== at 0x4C1C44C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==4747== by 0x108797: demoNew (testNew.cpp:15)
> ==4747== by 0x108797: main (testNew.cpp:20)
> ==4747== Address 0x4eb9d70 is 0 bytes inside a block of size 8 alloc'd
> ==4747== at 0x4C1B1F0: malloc (vg_replace_malloc.c:298)
> ==4747== by 0x4B56CAF: operator new(unsigned long)
> (stdlib_new_delete.cpp:33)
That reference above to 'operator new(unsigned long)' should have been
intercepted directly by valgrind, instead of first calling malloc() [which was
intercepted.] Valgrind does not know about "stdlib_new_delete.cpp". Which
shared library is it in?
> ==4747== by 0x10876F: demoNew (testNew.cpp:12)
> ==4747== by 0x10876F: main (testNew.cpp:20)
>
> localhost:/system/bin # nm -C ../lib64/libc.so | grep new
> 00000000000b2924 t operator new[](unsigned long)
> 00000000000b28d8 t operator new(unsigned long)
Again, I don't understand why libc.so has those functions.
Does it have also the corresponding 'delete' and 'delete[]'?
>
> localhost:/system/bin # nm -C ../lib64/libc++.so | grep new
> 000000000005cd1c W operator new[](unsigned long) 000000000005cc8c W
> operator new(unsigned long)
My working hypothesis is that appearance in libc.so of the code for some C++
operators, instead of appearing only in libc++.so, has confused valgrind. Also
note that the C++ 'operator new'
is a 'W' (weak global) symbol, but the plain-C symbol 'operator new'
is a 't' (strong local) symbol. A local symbol is not exported, so it is
visible only to calls from the same source file.
On the other hand, a weak symbol becomes hidden if there is any [visible]
strong definition. This is very confusing.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech
sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
