headers
Christopher Bergström | 3 May 2011 23:02
Favicon

Re: PathDB (non GPL/GNU debugger)

PathDB (debugger) has been ported to FreeBSD, but I thought others
around here may have some (mild) interest.

Summary:  x86/x86_64 debugger with the goal to drop-in replace gdb.
We recently finished some heavy refactoring and now focusing on
improving performance, *robustness*, scalability (clusters/multicore
systems), DWARF4, OS portability and supported targets.  PathDB has a
library based design with a cli interface doing direct function calls.
 Using C-bindings it should be fairly trivial to extend or add a new
front-end in python or other scripting language.

Source
git clone git://github.com/path64/debugger.git

Current status (heavy development - expect bugs)
GDB test suite results as of today (A lot of timeouts and at a glance
it seems like a lot of trivial CLI stuff)
FAIL: 747
PASS: 477

Log : https://gist.github.com/b44f708cc2242091bc20
---
Man page - http://www.pathscale.com/docs/pathdb.html
User guide (Needs to be updated) -
http://www.pathscale.com/docs/PathDB_UserGuide.pdf

We'd love feedback and more testers.  (It should be fairly easy to
port to NetBSD)

Bug reports can be sent to me directly or feel free to say hi on irc
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Klausner | 15 May 2011 13:08
Picon

Re: PathDB (non GPL/GNU debugger)

On Wed, May 04, 2011 at 04:02:00AM +0700, Christopher Bergström wrote:
> PathDB (debugger) has been ported to FreeBSD, but I thought others
> around here may have some (mild) interest.

I've made a simple git-based package for it and imported it to
pkgsrc/wip/debugger-git.

I didn't make any portability changes yet.
It currently doesn't build for a few reasons:

. calls hostname -f during cmake step (ignored)
. Unconditionally includes sys/procfs.h, which doesn't exist on NetBSD.
. Unconditionally includes thread_db.h, which doesn't exist on NetBSD.

Perhaps this reduces the barrier for others to try fixing it :)
 Thomas
Permalink | Reply | 1 comment |
headers
Christopher Bergström | 15 May 2011 13:51
Favicon

Re: PathDB (non GPL/GNU debugger)

2011/5/15 Thomas Klausner <wiz <at> netbsd.org>:
> On Wed, May 04, 2011 at 04:02:00AM +0700, Christopher Bergström wrote:
>> PathDB (debugger) has been ported to FreeBSD, but I thought others
>> around here may have some (mild) interest.
>
> I've made a simple git-based package for it and imported it to
> pkgsrc/wip/debugger-git.
>
> I didn't make any portability changes yet.
> It currently doesn't build for a few reasons:
>
> . calls hostname -f during cmake step (ignored)
> . Unconditionally includes sys/procfs.h, which doesn't exist on NetBSD.
> . Unconditionally includes thread_db.h, which doesn't exist on NetBSD.
>
> Perhaps this reduces the barrier for others to try fixing it :)

Cool - Thanks!

In no particular order here's what we're looking to work on..
1) Better portability
2) GDB compatibility
3) Extreme scalability
5) DWARF4
6) Scripting support (extending and embedding lua or python)

Is any of this particularly useful or interesting to others?  Anything
else people would care about?  I need to fish out the netbsd login
details I have and see if I can get one of our engineers to look at
the above issues.  The trouble spots are probably already wrapped in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joerg Sonnenberger | 17 May 2011 22:30
Picon

Compiler selection support

Hi all,
the attached patch allows more fine grained compiler selection.

(a) USETOOLS_GCC and USETOOLS_PCC are dropped. I don't really see the
point in them.

(b) AVAILABLE_COMPILER has a list of compilers tried in order to provide
a given language frontend. false is included as fallback to make sure
the variables always end up with something sensible.

(c) A compiler is choosen for a language if the corresponding tool
variable is set (e.g. TOOL_CC.gcc for the C frontend using GCC) and
it is not black listed in the current scope (e.g. UNSUPPORTED_COMPILER.pcc
says that PCC is not supported here). The decision is stored in
ACTIVE_CC etc, later to be used for compiler-specific flags like
COPTS_COMPILER.gcc.

Comments?

Joerg
Attachment (compiler.diff): text/x-diff, 2569 bytes
Permalink | Reply | 7 comments |
headers
Thomas Klausner | 20 May 2011 00:14
Picon

environ not found

It seems Linux defines environ(7) in libc itself, while in NetBSD it's
in crt0.o. While building libreoffice, I see

Making:    libosl_process.so
../../../unxbsdx3.pro/slo/osl_process.o: In function
`read_parent_environment(std::vector<std::string, rtl::Allocator<std::string> >*)':
osl_process.cxx:(.text+0x416): undefined reference to `environ'
osl_process.cxx:(.text+0x4a0): undefined reference to `environ'                                                                                                                                                   

The build process is a bit opaque to me. What linker (or compiler?)
flags could cause this or what needs to be added?

Thanks,
 Thomas
Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 20 May 2011 00:25
Picon

Re: environ not found

On Fri, May 20, 2011 at 12:14:41AM +0200, Thomas Klausner wrote:
> It seems Linux defines environ(7) in libc itself, while in NetBSD it's
> in crt0.o. While building libreoffice, I see
> 
> Making:    libosl_process.so
> ../../../unxbsdx3.pro/slo/osl_process.o: In function
`read_parent_environment(std::vector<std::string, rtl::Allocator<std::string> >*)':
> osl_process.cxx:(.text+0x416): undefined reference to `environ'
> osl_process.cxx:(.text+0x4a0): undefined reference to `environ'                                                                                                                                                   
Shared library built with -Wl,-z,defs. On -current you can use
-Wl,--ignore-unresolved-symbol,environ. Not sure when I added that.

Joerg
Permalink | Reply | 0 comments |
headers
Martin S. Weber | 20 May 2011 22:21
Picon

Re: Compiler selection support

On Tue, May 17, 2011 at 10:30:22PM +0200, Joerg Sonnenberger wrote:
> Hi all,
> the attached patch allows more fine grained compiler selection.
> (...)
> (c) A compiler is choosen for a language if the corresponding tool
> variable is set (e.g. TOOL_CC.gcc for the C frontend using GCC) and
> it is not black listed in the current scope (e.g. UNSUPPORTED_COMPILER.pcc
> says that PCC is not supported here). The decision is stored in
> ACTIVE_CC etc, later to be used for compiler-specific flags like
> COPTS_COMPILER.gcc.

Out of curiosity, how is C++ code that links to C libraries handled
in that framework? E.g. pcc (due to your patch) won't handle C++. Now
there's still some C++ in base, isn't there? won't there be problems
with gcc-compiled c++ that tries to link to pcc compiled C libs?

Regards,
-Martin
Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 20 May 2011 23:11
Picon

Re: Compiler selection support

On Fri, May 20, 2011 at 10:21:45PM +0200, Martin S. Weber wrote:
> On Tue, May 17, 2011 at 10:30:22PM +0200, Joerg Sonnenberger wrote:
> > Hi all,
> > the attached patch allows more fine grained compiler selection.
> > (...)
> > (c) A compiler is choosen for a language if the corresponding tool
> > variable is set (e.g. TOOL_CC.gcc for the C frontend using GCC) and
> > it is not black listed in the current scope (e.g. UNSUPPORTED_COMPILER.pcc
> > says that PCC is not supported here). The decision is stored in
> > ACTIVE_CC etc, later to be used for compiler-specific flags like
> > COPTS_COMPILER.gcc.
> 
> Out of curiosity, how is C++ code that links to C libraries handled
> in that framework? E.g. pcc (due to your patch) won't handle C++. Now
> there's still some C++ in base, isn't there? won't there be problems
> with gcc-compiled c++ that tries to link to pcc compiled C libs?

Why? There is still the issue of unifying the runtime libraries, but
otherwise it should be fine.

Joerg
Permalink | Reply | 0 comments |
headers
David Laight | 23 May 2011 20:21
Picon

ld finding the wrong library

I've just tracked down why I've been failing to build xinit.

The link command used is:

/bsd/current/obj_amd64/tools/tools.NetBSD-amd64/bin/x86_64--netbsd-gcc   
--sysroot=/bsd/current/dest_amd64 -Wl,-rpath,/usr/X11R7/lib -L=/usr/X11R7/lib
    -o xinput  buttonmap.o feedback.o list.o property.o setint.o setmode.o
setptr.o state.o test.o xinput.o -lXi -lm      
-Wl,-rpath-link,/bsd/current/dest_amd64/lib  -L=/lib

and I get an error because XESetWireToEventCookie is undefined.
XESetWireToEventCookie() is referenced in libXi.so and should be
defined by libX11.so

However since there is no -lX11 (or a direct reference to libX11.so)
libX11.so is looked for because of the NEEDED entry in libXi.so.
However libXi.so has an RPATH entry for /usr/X11R7/lib, and the linker
is looking there first.
On my system the installed libX11.so is dated from late 2009 and doesn't
have XESetWireToEventCookie - so the link fails.

Maybe the --sysroot should affect this - but it doesn't.

I've also noticed that ld is adding a NEEDED entry for libX11.so into
the xinput program - surely this is wrong.

I've changed the Makefile for xinput to explicitly specify -lX11
to make the build not reference installed libraries.

	David
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Laight | 23 May 2011 20:22
Picon

Re: ld finding the wrong library

On Mon, May 23, 2011 at 07:21:04PM +0100, David Laight wrote:
> I've just tracked down why I've been failing to build xinit.

xinput :-)

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |

Gmane