On Mon, May 7, 2018 at 1:59 PM, Cillian O'Donnell <cpodonne...@gmail.com> wrote:
> > > On 7 May 2018 at 18:56, Joel Sherrill <j...@rtems.org> wrote: > >> Hi >> >> I have attached a workaround. It seems that libgen.h has this: >> >> ======================================================== >> /* Return final component of PATH. >> >> This is the weird XPG version of this function. It sometimes will >> modify its argument. Therefore we normally use the GNU version (in >> <string.h>) and only if this header is included make the XPG >> version available under the real name. */ >> extern char *__xpg_basename (char *__path) __THROW; >> #define basename __xpg_basename >> ======================================================== >> >> Chris has used basename as a method name and even though that should >> be perfectly acceptable, the macro above gets expanded, the name >> gets changed (in some places) to rld::path::__xpg_basename() >> >> r.lowSourceLine = rld::path::basename (location); >> >> IMO the fix is to add dirname to rld-files, use rld basename and dirname >> exclusively, and avoid libgen.h at all costs. >> >> I didn't do that much work. I got lucky in a couple of files by removing >> the >> include of libgen.h since it wasn't needed but I had to leave it in one >> place. >> >> $ grep dirname *.cc >> GcovData.cc: dirname( path ); >> >> Hopefully this lets you all proceed with Chris' patches and my slight hack >> in place. >> > > Thanks Joel! The good news is that's building now with only a couple of > warnings. > > The bad news is.. > > cpod@cpod ~/development/rtems/leon3 $ covoar -S > /home/cpod/development/rtems/test/rtems-tools/tester/rtems/ > testing/coverage/score-symbols.ini -O /home/cpod/coverage_test/test/score > -E/home/cpod/development/rtems/test/rtems-tools/tester/ > rtems/testing/coverage/Explanations.txt -p RTEMS-5 -v > sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe > *** Error in `covoar': free(): invalid next size (fast): > 0x0000000001000360 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fcd0b3477e5] > /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fcd0b35037a] > /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fcd0b35453c] > covoar[0x43fcee] > covoar[0x42bc4a] > covoar[0x42d205] > covoar[0x40dec5] > covoar[0x4054b6] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fcd0b2f0830] > covoar[0x4073e9] > ======= Memory map: ======== > 00400000-004a8000 r-xp 00000000 08:07 3276534 > /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar > 006a7000-006a8000 r--p 000a7000 08:07 3276534 > /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar > 006a8000-006a9000 rw-p 000a8000 08:07 3276534 > /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar > 006a9000-006aa000 rw-p 00000000 00:00 0 > 00c6a000-01022000 rw-p 00000000 00:00 0 > [heap] > 7fcd04000000-7fcd04021000 rw-p 00000000 00:00 0 > 7fcd04021000-7fcd08000000 ---p 00000000 00:00 0 > 7fcd0a9ae000-7fcd0ac36000 rw-p 00000000 00:00 0 > 7fcd0ac36000-7fcd0afc7000 r--p 00000000 08:07 2759194 > /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/ > testsuites/samples/hello/hello.exe > 7fcd0afc7000-7fcd0b0cf000 r-xp 00000000 08:07 1838070 > /lib/x86_64-linux-gnu/libm-2.23.so > 7fcd0b0cf000-7fcd0b2ce000 ---p 00108000 08:07 1838070 > /lib/x86_64-linux-gnu/libm-2.23.so > 7fcd0b2ce000-7fcd0b2cf000 r--p 00107000 08:07 1838070 > /lib/x86_64-linux-gnu/libm-2.23.so > 7fcd0b2cf000-7fcd0b2d0000 rw-p 00108000 08:07 1838070 > /lib/x86_64-linux-gnu/libm-2.23.so > 7fcd0b2d0000-7fcd0b490000 r-xp 00000000 08:07 1842682 > /lib/x86_64-linux-gnu/libc-2.23.so > 7fcd0b490000-7fcd0b690000 ---p 001c0000 08:07 1842682 > /lib/x86_64-linux-gnu/libc-2.23.so > 7fcd0b690000-7fcd0b694000 r--p 001c0000 08:07 1842682 > /lib/x86_64-linux-gnu/libc-2.23.so > 7fcd0b694000-7fcd0b696000 rw-p 001c4000 08:07 1842682 > /lib/x86_64-linux-gnu/libc-2.23.so > 7fcd0b696000-7fcd0b69a000 rw-p 00000000 00:00 0 > 7fcd0b69a000-7fcd0b6b0000 r-xp 00000000 08:07 1836727 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fcd0b6b0000-7fcd0b8af000 ---p 00016000 08:07 1836727 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fcd0b8af000-7fcd0b8b0000 rw-p 00015000 08:07 1836727 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7fcd0b8b0000-7fcd0ba22000 r-xp 00000000 08:07 1049309 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 > 7fcd0ba22000-7fcd0bc22000 ---p 00172000 08:07 1049309 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 > 7fcd0bc22000-7fcd0bc2c000 r--p 00172000 08:07 1049309 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 > 7fcd0bc2c000-7fcd0bc2e000 rw-p 0017c000 08:07 1049309 > /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 > 7fcd0bc2e000-7fcd0bc32000 rw-p 00000000 00:00 0 > 7fcd0bc32000-7fcd0bc58000 r-xp 00000000 08:07 1838072 > /lib/x86_64-linux-gnu/ld-2.23.so > 7fcd0bd72000-7fcd0be30000 rw-p 00000000 00:00 0 > 7fcd0be56000-7fcd0be57000 rw-p 00000000 00:00 0 > 7fcd0be57000-7fcd0be58000 r--p 00025000 08:07 1838072 > /lib/x86_64-linux-gnu/ld-2.23.so > 7fcd0be58000-7fcd0be59000 rw-p 00026000 08:07 1838072 > /lib/x86_64-linux-gnu/ld-2.23.so > 7fcd0be59000-7fcd0be5a000 rw-p 00000000 00:00 0 > 7ffc5053b000-7ffc5055d000 rw-p 00000000 00:00 0 > [stack] > 7ffc505d5000-7ffc505d7000 r--p 00000000 00:00 0 > [vvar] > 7ffc505d7000-7ffc505d9000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > Aborted > OK. Sadly this is progress. :) Can you get a real backtrace in gdb? Or run it under valgrind? It is either a double free or a write past the end of a buffer. Based on the error mesage from glibc (" *** Error in `covoar': free(): invalid next size (fast): 0x0000000001000360 ***"), I suspect it is a write past the end of a buffer and valgrind would be better to spot that. > > >> Ultimate solution is probably simple. We just need to hear from Chris. >> >> --joel >> >> >> On Mon, May 7, 2018 at 12:42 PM, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Mon, May 7, 2018 at 12:36 PM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> >>>> On Mon, 7 May 2018, 22:57 Cillian O'Donnell, <cpodonne...@gmail.com> >>>> wrote: >>>> >>>>> Yeah I'm seeing the same as Joel, at least were further then we were >>>>> :). >>>>> >>>>> I've been mostly working on the rtems-tester support, so just to give >>>>> an update. I spent all day Saturday and today on it. It's taking longer >>>>> than expected, re-orienting myself and deciding what is needed and not >>>>> needed now with the changes in covoar. The problems are not difficult, >>>>> it's >>>>> just taking some time re-organizing everything. My time is limited during >>>>> the week, so it'll probably be next weekend before I can finish it off. >>>>> Vijay if you have time during the week I could push what I have and you >>>>> could take a stab at some of them and then I could it finish off next >>>>> weekend if you haven't already. >>>>> >>>> please send them, I can look into them for sure. >>>> >>> >>> Keep plugging away. >>> >>> I think there is something wrong in rld related to basename. My first >>> thought was that the undefined symbol was because we didn't include the >>> library. Now I think it is because something got misconfigured on >>> Centos/Fedora/etc. Looking into this. >>> >>> >>>> >>>>> On 7 May 2018 at 15:40, Joel Sherrill <j...@rtems.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, May 7, 2018 at 6:01 AM, Vijay Kumar Banerjee < >>>>>> vijaykumar9...@gmail.com> wrote: >>>>>> >>>>>>> I have added the path to libdwarf here >>>>>>> >>>>>> >>>>>> That worked for me to build but not to link. >>>>>> >>>>>> I'm not sure why this rld symbol turned up missing on Centos 7. >>>>>> >>>>>> ==================================================== >>>>>> >>>>>> $ ./waf -v >>>>>> Waf: Entering directory `/home/joel/rtems-work/rtems-tools/build' >>>>>> [228/229] Linking build/tester/covoar/trace-converter >>>>>> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/TraceConverter.cc.2.o', >>>>>> 'tester/covoar/TraceList.cc.2.o', 'tester/covoar/TraceReaderBase.cc.2.o', >>>>>> 'tester/covoar/TraceReaderLogQEMU.cc.2.o', >>>>>> 'tester/covoar/TraceWriterBase.cc.2.o', >>>>>> 'tester/covoar/TraceWriterQEMU.cc.2.o', >>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/trace-converter', >>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', >>>>>> '-lrld', >>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic'] >>>>>> [229/229] Linking build/tester/covoar/covoar >>>>>> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o', >>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/covoar', >>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', >>>>>> '-lrld', >>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic'] >>>>>> tester/covoar/libccovoar.a(DesiredSymbols.cc.1.o): In function >>>>>> `Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*, >>>>>> Coverage::ExecutableInfo*)': >>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:413: >>>>>> undefined reference to `rld::path::__xpg_basename(std::string >>>>>> const&)' >>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:415: >>>>>> undefined reference to `rld::path::__xpg_basename(std::string >>>>>> const&)' >>>>>> collect2: error: ld returned 1 exit status >>>>>> >>>>>> tester/covoar/libccovoar.a(DesiredSymbols.cc.1.o): In function >>>>>> `Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*, >>>>>> Coverage::ExecutableInfo*)': >>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:413: >>>>>> undefined reference to `rld::path::__xpg_basename(std::string >>>>>> const&)' >>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:415: >>>>>> undefined reference to `rld::path::__xpg_basename(std::string >>>>>> const&)' >>>>>> collect2: error: ld returned 1 exit status >>>>>> >>>>>> Waf: Leaving directory `/home/joel/rtems-work/rtems-tools/build' >>>>>> Build failed >>>>>> -> task in 'trace-converter' failed with exit status 1: >>>>>> {task 34721616: cxxprogram TraceConverter.cc.2.o,TraceLis >>>>>> t.cc.2.o,TraceReaderBase.cc.2.o,TraceReaderLogQEMU.cc.2.o,Tr >>>>>> aceWriterBase.cc.2.o,TraceWriterQEMU.cc.2.o -> trace-converter} >>>>>> ['/usr/bin/g++', 'tester/covoar/TraceConverter.cc.2.o', >>>>>> 'tester/covoar/TraceList.cc.2.o', 'tester/covoar/TraceReaderBase.cc.2.o', >>>>>> 'tester/covoar/TraceReaderLogQEMU.cc.2.o', >>>>>> 'tester/covoar/TraceWriterBase.cc.2.o', >>>>>> 'tester/covoar/TraceWriterQEMU.cc.2.o', >>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/trace-converter', >>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', >>>>>> '-lrld', >>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic'] >>>>>> -> task in 'covoar' failed with exit status 1: >>>>>> {task 34820256: cxxprogram covoar.cc.3.o -> covoar} >>>>>> ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o', >>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/covoar', >>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', >>>>>> '-lrld', >>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic'] >>>>>> ==================================================== >>>>>> >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> diff --git a/tester/covoar/wscript b/tester/covoar/wscript >>>>>>> index 55d5ec9..dd4ad83 100644 >>>>>>> --- a/tester/covoar/wscript >>>>>>> +++ b/tester/covoar/wscript >>>>>>> @@ -63,6 +63,7 @@ def build(bld): >>>>>>> rtl_includes = [rtemstoolkit, >>>>>>> rtemstoolkit + '/elftoolchain/libelf', >>>>>>> rtemstoolkit + '/elftoolchain/common', >>>>>>> + rtemstoolkit + '/elftoolchain/libdwarf', >>>>>>> rtemstoolkit + '/libiberty'] >>>>>>> if bld.env.DEST_OS == 'win32': >>>>>>> rtl_includes += [rtemstoolkit + '/win32'] >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- vijay >>>>>>> >>>>>>> On 7 May 2018 at 13:30, Vijay Kumar Banerjee < >>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 6 May 2018 at 13:29, Chris Johns <chr...@rtems.org> wrote: >>>>>>>> >>>>>>>>> On 6/5/18 5:28 pm, Vijay Kumar Banerjee wrote: >>>>>>>>> >>>>>>>>>> On 6 May 2018 at 08:54, Chris Johns <chr...@rtems.org <mailto: >>>>>>>>>> chr...@rtems.org>> wrote: >>>>>>>>>> >>>>>>>>>> Would you please try `waf clean build` to see if >>>>>>>>>> rebuilding >>>>>>>>>> everything fixes this? >>>>>>>>>> >>>>>>>>>> still getting the same error . >>>>>>>>>> I'm using g++ 7.3.1 on fedora 27. >>>>>>>>>> >>>>>>>>> >>>>>>>>> OK >>>>>>>>> >>>>>>>>> If you have changed something in the code, can you please send a >>>>>>>>>> patch for the same ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I have not changed anything. I do not have a Linux box to try. >>>>>>>>> >>>>>>>>> I tried to do it afresh as well, it's still failing to build. >>>>>>>> Can someone please try to build it in a linux system ? >>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> devel mailing list >>>>>>> devel@rtems.org >>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> devel@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>> >>>>> >>>>> >>> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel