Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Joel Sherrill]

On Mon, May 7, 2018 at 5:09 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 08/05/2018 07:32, Joel Sherrill wrote:
> > On Mon, May 7, 2018 at 3:58 PM, Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 08/05/2018 03:56, Joel Sherrill wrote:
> >     >
> >     > I have attached a workaround.
> >
> >     Looks like a solution to me.
> >
> >
> > Good enough for now. All basename() calls should come from rld.
> >
> > Eventually all dirname() calls should also.
> >
> > Luckily no file uses both so we don't have to include libgen.h when
> > for dirname() and screw up basename().
>
> Works on FreeBSD ;)
>
> >     > 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
> >     > ========================================================
> >     >
> >
> >     Oh yuck, who would ever work in standards. ;)
> >
> >     Is this function allowed to be redefined as a macro?
> >
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
> >
> > Neither seems to say anything about that. Both have language like this:
> >
> > " The /dirname/() function may modify the string pointed to by /path/,
> and may
> > return a pointer to static storage that may then be overwritten by a
> subsequent
> > call to /dirname/()."
> >
> > It really would be better to have our own implementations and not
> > use the standard basename() and dirname(). The POSIX ones
> > are not thread-safe.
>
> We have them in rld-path. It is a little like the python os.path module.
>
> >
> >     > 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.
> >
> >     Wouldn't the world be so much simpler if there was only Linux? ;)
> >
> >
> > The methods as defined by POSIX aren't thread-safe and can
> > modify the caller's string. Suck by design. :)
> >
> > Having one mono-culture is easy but it doesn't make it right
> > even when conformant. :)
>
> It is a horrible implementation and not safe in C++.
>

Not safe in C. Just not safe.

>
> >
> >     > 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.
> >     >
> >     > Ultimate solution is probably simple. We just need to hear from
> Chris.
> >
> >     This is fine. I am slowing move covoar to use more and more of the
> rtemstoolkit.
> >
> >     I will merge these changes into a v2 patch set.
> >
> >
> > Are you adding dirname()? Or does that need a ticket?
> >
>
> Confused....
>
> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-path.h#n52


I missed that somehow. There was one call in covoar to the OS method. Just
replace it
and remove the libgen.h reference. Easy. :)

--joel


>
>
> ?
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180507/af446826/attachment-0002.html>