You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(1) |
3
|
|
4
|
5
|
6
(2) |
7
(2) |
8
(3) |
9
(4) |
10
|
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
|
25
(1) |
26
|
27
|
28
(1) |
29
|
30
|
|
|
From: <Jos...@gm...> - 2021-04-08 20:30:44
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi,</div> <div> </div> <div>you are confusing .plt.got with got.plt :-)</div> <div>Obviously both can exist.</div> <div> </div> <div>Here some output from "objdump -C -S qcachegrind", a Qt application, showing the</div> <div>code in ".plt.got" and ".plt.sec". I have no idea why only the shown 2 entries show</div> <div>up in ".plt.got" here.</div> <div>GCC is "gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)".</div> <div> </div> <div>=================================================</div> <div> <div>Disassembly of section .plt:<br/> <br/> 0000000000030020 <.plt>:<br/> 30020: ff 35 22 05 12 00 pushq 0x120522(%rip) # 150548 <_GLOBAL_OFFSET_TABLE_+0x8><br/> 30026: f2 ff 25 23 05 12 00 bnd jmpq *0x120523(%rip) # 150550 <_GLOBAL_OFFSET_TABLE_+0x10><br/> 3002d: 0f 1f 00 nopl (%rax)<br/> 30030: f3 0f 1e fa endbr64 <br/> 30034: 68 00 00 00 00 pushq $0x0<br/> 30039: f2 e9 e1 ff ff ff bnd jmpq 30020 <.plt><br/> 3003f: 90 nop</div> <div>.....</div> <div> </div> <div>Disassembly of section .plt.got:<br/> <br/> 0000000000033010 <QProcessEnvironment::~QProcessEnvironment()@plt>:<br/> 33010: f3 0f 1e fa endbr64 <br/> 33014: f2 ff 25 ad ed 11 00 bnd jmpq *0x11edad(%rip) # 151dc8 <QProcessEnvironment::~QProcessEnvironment()@Qt_5><br/> 3301b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)<br/> <br/> 0000000000033020 <__cxa_finalize@plt>:<br/> 33020: f3 0f 1e fa endbr64 <br/> 33024: f2 ff 25 9d ee 11 00 bnd jmpq *0x11ee9d(%rip) # 151ec8 <__cxa_finalize@GLIBC_2.2.5><br/> 3302b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)<br/> <br/> Disassembly of section .plt.sec:<br/> <br/> 0000000000033030 <QHeaderView::setSectionResizeMode(QHeaderView::ResizeMode)@plt>:<br/> 33030: f3 0f 1e fa endbr64 <br/> 33034: f2 ff 25 1d d5 11 00 bnd jmpq *0x11d51d(%rip) # 150558 <QHeaderView::setSectionResizeMode(QHeaderView::ResizeMode)@Qt_5><br/> 3303b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)<br/> <br/> 0000000000033040 <QTreeView::sortByColumn(int, Qt::SortOrder)@plt>:<br/> 33040: f3 0f 1e fa endbr64 <br/> 33044: f2 ff 25 15 d5 11 00 bnd jmpq *0x11d515(%rip) # 150560 <QTreeView::sortByColumn(int, Qt::SortOrder)@Qt_5><br/> 3304b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)</div> <div>..........</div> <div> <div>=================================================</div> <div> </div> <div>See also this LLVM discussion: https://reviews.llvm.org/D59780</div> <div>The LLVM-10/11 linker "lld" on my laptop generates also the ".plt.sec" sections.</div> <div> </div> <div> <div>I really think that ".plt.got" and ".plt.sec" should be recognized as PLT sections by Valgrind.</div> </div> <div>Cheers,</div> <div>Josef</div> <div> </div> <b>Gesendet:</b> Donnerstag, 08. April 2021 um 08:09 Uhr <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Von:</b> "Tom Hughes" <to...@co...><br/> <b>An:</b> Jos...@gm..., val...@li...<br/> <b>Betreff:</b> Re: Proposed patch to recognize .plt.got and .plt.sec as PLT sections</div> <div name="quoted-content">I don't think .plt.got contains code does it? Rather it contains the<br/> addresses used by the indirect jumps in the main .plt section.</div> <div name="quoted-content"><br/> Essentially the vectors in .plt contain code like:<br/> <br/> jmp *x<br/> <br/> Where x in an address in .plt.got that initially contains the<br/> address of the resolver function and is then patched to contain<br/> the actual function address after it is resolved.<br/> <br/> As such I wouldn't expect addresses in .plt.got to appear in<br/> any back traces.<br/> <br/> Tom<br/> <br/> On 08/04/2021 01:16, Jos...@gm... wrote:<br/> > Hi,<br/> > see attached patch to let the debuginfo module detect the sections<br/> > ".plt.got" and ".plt.sec" as PLT sections.<br/> > Both these sections appear in binaries of e.g. Ubuntu 20.4, and they<br/> > are obviously trampolines for shared lib calls, ie like other entries in<br/> > a regular ".plt" section. E.g. the ".plt.sec" section is added to the<br/> > amd64 ABI for support of Intel CET, which obviously is enabled for<br/> > all Ubuntu 20.04 packages (since last year).<br/> > Not so sure about the purpuse of ".plt.got"...<br/> > For better results, Callgrind suppresses calls to code in PLT sections<br/> > in the<br/> > generated call graph (instead, cost is attributed to the caller).<br/> > Without this, calls<br/> > to shared lib functions do show up as calls routed via unnamed functions<br/> > (specifeid as hex address), as VG does not load symbols from PLT sections.<br/> > This is currently happening on Ubuntu 20.04 (in addition to missing<br/> > special handling<br/> > of _dl_runtime_resolve_xsave, for what I just committed a fix).<br/> > I am a bit unsure about these aspects of the attached patch:<br/> > - no new section type is added, but VG_(DebugInfo_sect_kind) returns<br/> > Vg_SectPLT<br/> > now also for addresses within ".plt.sec" and ".plt.got"<br/> > - for loading symbol names, the new sections are treated like ".plt",<br/> > ie. VG refuses<br/> > to add symbols from these sections<br/> > I think the latter is fine, but I am unsure about the first, esp as VG<br/> > also distinguishes<br/> > GOT and GOTPLT sections. Next to Callgrind, DRD and Helgrind check for<br/> > Vg_SectPLT<br/> > at some point, and it looks fine to me to keep the single section type<br/> > Vg_SectPLT,<br/> > but wanted to check before applying the patch.<br/> > Thanks,<br/> > Josef<br/> ><br/> > EMail Address: Jos...@gm...<br/> ><br/> ><br/> > _______________________________________________<br/> > Valgrind-developers mailing list<br/> > Val...@li...<br/> > <a href="https://lists.sourceforge.net/lists/listinfo/valgrind-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/valgrind-developers</a><br/> ><br/> <br/> <br/> --<br/> Tom Hughes (to...@co...)<br/> <a href="http://compton.nu/" target="_blank">http://compton.nu/</a></div> </div> </div> </div> </div></div></body></html> |
|
From: Tom H. <to...@co...> - 2021-04-08 06:48:03
|
I don't think .plt.got contains code does it? Rather it contains the addresses used by the indirect jumps in the main .plt section. Essentially the vectors in .plt contain code like: jmp *x Where x in an address in .plt.got that initially contains the address of the resolver function and is then patched to contain the actual function address after it is resolved. As such I wouldn't expect addresses in .plt.got to appear in any back traces. Tom On 08/04/2021 01:16, Jos...@gm... wrote: > Hi, > see attached patch to let the debuginfo module detect the sections > ".plt.got" and ".plt.sec" as PLT sections. > Both these sections appear in binaries of e.g. Ubuntu 20.4, and they > are obviously trampolines for shared lib calls, ie like other entries in > a regular ".plt" section. E.g. the ".plt.sec" section is added to the > amd64 ABI for support of Intel CET, which obviously is enabled for > all Ubuntu 20.04 packages (since last year). > Not so sure about the purpuse of ".plt.got"... > For better results, Callgrind suppresses calls to code in PLT sections > in the > generated call graph (instead, cost is attributed to the caller). > Without this, calls > to shared lib functions do show up as calls routed via unnamed functions > (specifeid as hex address), as VG does not load symbols from PLT sections. > This is currently happening on Ubuntu 20.04 (in addition to missing > special handling > of _dl_runtime_resolve_xsave, for what I just committed a fix). > I am a bit unsure about these aspects of the attached patch: > - no new section type is added, but VG_(DebugInfo_sect_kind) returns > Vg_SectPLT > now also for addresses within ".plt.sec" and ".plt.got" > - for loading symbol names, the new sections are treated like ".plt", > ie. VG refuses > to add symbols from these sections > I think the latter is fine, but I am unsure about the first, esp as VG > also distinguishes > GOT and GOTPLT sections. Next to Callgrind, DRD and Helgrind check for > Vg_SectPLT > at some point, and it looks fine to me to keep the single section type > Vg_SectPLT, > but wanted to check before applying the patch. > Thanks, > Josef > > EMail Address: Jos...@gm... > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: <Jos...@gm...> - 2021-04-08 00:16:20
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div> </div> <div>see attached patch to let the debuginfo module detect the sections</div> <div>".plt.got" and ".plt.sec" as PLT sections.</div> <div> </div> <div>Both these sections appear in binaries of e.g. Ubuntu 20.4, and they</div> <div>are obviously trampolines for shared lib calls, ie like other entries in</div> <div>a regular ".plt" section. E.g. the ".plt.sec" section is added to the</div> <div>amd64 ABI for support of Intel CET, which obviously is enabled for</div> <div>all Ubuntu 20.04 packages (since last year).</div> <div>Not so sure about the purpuse of ".plt.got"...</div> <div> </div> <div>For better results, Callgrind suppresses calls to code in PLT sections in the</div> <div>generated call graph (instead, cost is attributed to the caller). Without this, calls</div> <div>to shared lib functions do show up as calls routed via unnamed functions</div> <div>(specifeid as hex address), as VG does not load symbols from PLT sections.</div> <div>This is currently happening on Ubuntu 20.04 (in addition to missing special handling</div> <div>of _dl_runtime_resolve_xsave, for what I just committed a fix).</div> <div> </div> <div>I am a bit unsure about these aspects of the attached patch:</div> <div>- no new section type is added, but VG_(DebugInfo_sect_kind) returns Vg_SectPLT</div> <div> now also for addresses within ".plt.sec" and ".plt.got"</div> <div>- for loading symbol names, the new sections are treated like ".plt", ie. VG refuses</div> <div> to add symbols from these sections</div> <div> </div> <div>I think the latter is fine, but I am unsure about the first, esp as VG also distinguishes</div> <div>GOT and GOTPLT sections. Next to Callgrind, DRD and Helgrind check for Vg_SectPLT</div> <div>at some point, and it looks fine to me to keep the single section type Vg_SectPLT,</div> <div>but wanted to check before applying the patch.</div> <div> </div> <div>Thanks,</div> <div>Josef</div> <div> </div> <div> </div> <div> <div class="signature"><br/> EMail Address: Jos...@gm...</div> </div></div></body></html> |