headers
Ignatios Souvatzis | 6 Jun 2005 21:59
Picon

Shark X server: 1.6. on 2.0.2 crashes

Hi,

I've tried to run the 1.6.2 X server on my 2.0.2 shark, but it crashes
with SEGV (apparently due to stack overflow because of an infinite
rtld_something call) - see below for details.

I think scw told me this shoudl work... what might I be doing wrong?

Regards,
	-is

-u 
seang debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/is/XF86_SVGA 
(no debugging symbols found)...(no debugging symbols found)...

XFree86 Version 3.3.6a / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: November 30 2000
        If the server is older than 6-12 months, or if your card is newer
        than the above date, look for a newer version before reporting
        problems.  (see http://www.XFree86.Org/FAQ)
Operating System: NetBSD/shark 1.5ZC [ELF] The NetBSD Foundation, Inc.
Configured drivers:
  SVGA: server for SVGA graphics adaptors (Patchlevel 1):
      ct65520, ct65525, ct65530, ct65535, ct65540, ct65545, ct65546,
      ct65548, ct65550, ct65554, ct65555, ct68554, ct69000, ct64200,
      ct64300, CyberPro2010, generic
Using pccons driver with X support
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ignatios Souvatzis | 13 Jun 2005 15:32
Picon

Shark X server: 1.6. on 3.0_BETA crashes (BPT trap)

Followup:

I've run the 1.6.2 X server on NetBSD/shark 2.0.2 with a 3.0_BETA kernel,
and it runs most of the time... unless I start viewfax and resize it 
(which seems to happen automatically when it it started in the presence
of a window manager...)

The X server dies with "EMT/BPT trap" . I vaguely recall having seen 
this a long while ago, and that somebody told me a workaround, but can't
remember right now. Does anybody know what I'm talking about?

Regards,
	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 2 comments |
headers
Ignatios Souvatzis | 13 Jun 2005 21:22
Picon

Re: Shark X server: 1.6. on 3.0_BETA crashes (BPT trap)

On Wed, Jun 15, 2005 at 03:35:17PM +0200, Ignatios Souvatzis wrote:
> Followup:
> 
> I've run the 1.6.2 X server on NetBSD/shark 2.0.2 with a 3.0_BETA kernel,
> and it runs most of the time... unless I start viewfax and resize it 
> (which seems to happen automatically when it it started in the presence
> of a window manager...)
> 
> The X server dies with "EMT/BPT trap" . I vaguely recall having seen 
> this a long while ago, and that somebody told me a workaround, but can't
> remember right now. Does anybody know what I'm talking about?

actually, viewfax is innocent.
I get the same effect with xli when zooming into a small picture created
by pbmtext.

Promoting the same to a pgm allowed me to zoom in/out, rotate etc. 
without problems.

Regards,
	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 1 comment |
headers
Ignatios Souvatzis | 14 Jun 2005 10:52
Picon

Re: Shark X server: 1.6. on 3.0_BETA crashes (BPT trap)

On Mon, Jun 13, 2005 at 09:22:44PM +0200, Ignatios Souvatzis wrote:

> (BPT trap in XF86_SVGA)

I've seen this with different triggers earlier - see PR 21484.

Regards,
	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 0 comments |
headers
Steve Woodford | 19 Jun 2005 13:14
Picon

ARM mapping symbols in the kernel

Hi,

While bringing up the kernel on an ARM-based board recently, I ran into a 
problem cause by binutils-2.15. In a nutshell, this version of binutils 
adds ARM mapping symbols to every arm32 object file.

For the uninitiated, ARM mapping symbols provide a way to mark arm32 and 
thumb instructions, and also data embedded within .text. The ARM ELF 
spec requires these special symbols exist for various reasons, not least 
of which is accurate disassembly.

The symbols take the form "$a" for arm32 insns, "$t" for thumb insns, and 
"$d" for data. The trouble starts when they get into the kernel's symbol 
table. In many cases these symbols take the same value as regular 
symbols (there are multiple instances of these mapping symbols), this 
leads to mass confusion in ddb(9), for example. The result is that 
nearly all calls to db_printsym() end up displaying the raw address 
instead of the correct symbol+offset. This is because db_printsym() does 
a forward lookup on the address which returns, say "$a", then does a 
reverse lookup with "$a" to compare the address. This almost always 
fails since the reverse lookup always returns the address of the *first* 
instance of "$a".

Also, it's no surprise to note that since binutils-2.15 was imported, 
there have been quite a few commits of the form "Bump SYMTAB_SPACE" for 
our arm32 ports...

There is a thread on this subject here:

http://lists.gnu.org/archive/html/bug-binutils/2004-07/msg00041.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Earnshaw | 19 Jun 2005 18:35
Picon
Picon

Re: ARM mapping symbols in the kernel

On Sun, 19 Jun 2005 12:14:45 BST, Steve Woodford wrote:

> As a local work-around, I have added some code in 
> kern_ksyms.c:addsymtab() which skips mapping symbols if __arm__ is 
> defined. But I'd prefer something like the objcopy(1) option mentioned 
> in the above thread.
> 

objcopy --strip-symbol '$d' --strip-symbol '$a' --strip-symbol '$t'

should do the trick.

R.
Permalink | Reply | 0 comments |
headers
Steve Woodford | 19 Jun 2005 20:40
Picon

Re: ARM mapping symbols in the kernel

On Sunday 19 June 2005 17:35, Richard Earnshaw wrote:
> On Sun, 19 Jun 2005 12:14:45 BST, Steve Woodford wrote:
> > As a local work-around, I have added some code in
> > kern_ksyms.c:addsymtab() which skips mapping symbols if __arm__ is
> > defined. But I'd prefer something like the objcopy(1) option
> > mentioned in the above thread.
>
> objcopy --strip-symbol '$d' --strip-symbol '$a' --strip-symbol '$t'

Now why didn't I think of that...

Thanks, Richard!

Cheers, Steve
Permalink | Reply | 0 comments |

Gmane