On Fri, Sep 20, 2019 at 11:24:53AM +0100, Patrick Welche wrote:
> > I'll do a MKUPDATE=no build...
>
> It seems that MKUPDATE=yes and MKDEBUG=yes don't do what one might
> hope for...
It works fine if you started with a MKDEBUG=yes build, but it will not
properly create debug info for things
On Thu, Sep 19, 2019 at 04:43:57PM +0100, Patrick Welche wrote:
> On Thu, Sep 19, 2019 at 05:41:28PM +0200, Martin Husemann wrote:
> > Something wrong with your debug sets?
>
> I just finished a build.sh and specifically have MKDEBUG=yes.
> Oddly I just rebuilt rump_server with DBG=-ggdb -O0,
On Thu, Sep 19, 2019 at 05:41:28PM +0200, Martin Husemann wrote:
> Something wrong with your debug sets?
I just finished a build.sh and specifically have MKDEBUG=yes.
Oddly I just rebuilt rump_server with DBG=-ggdb -O0, MKSTRIPSYM=no,
and then
Reading symbols from /usr/bin/rump_server...
Reading
Different computer which has fresh sets. Why can crash do better than gdb?
[I am not convinced that gdb is currently useful - got to the previous
message as I kept getting "registers not found" message just trying to
set a breakpoint in a rump kernel]
# crash -M netbsd.1.core -N netbsd.1
Crash
On Thu, Sep 19, 2019 at 04:27:44PM +0100, Patrick Welche wrote:
> I'm pretty sure gdb used to pick up symbols automatically, but now I see
> on a fresh -current/amd64 box (with a nod to PR/38185):
>
> $ gdb `which calendar`
> GNU gdb (GDB) 8.3
> ...
> Reading symbols from /usr/bin/calendar...
>
