headers
Zhang, Sonic | 14 Feb 2007 04:07
Favicon

Re: sigaltstack obsoleted?

Because the review comments from LKML said that we should remove this
obsolete syscall.
I can rollback this syscall in our svn till it is also obsolete in gdb
regression too. 

Sonic

-----Original Message-----
From: Jie Zhang [mailto:jzhang918@...] 
Sent: Wednesday, February 14, 2007 12:52 AM
To: Zhang, Sonic
Cc: uclinux-dist-devel@...
Subject: sigaltstack obsoleted?

Hi Sonic,

Why sigaltstack was removed from bfin linux kernel? Why did you say it's
obsoleted?

https://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?action=brow
se&path=%2F&view=rev&revision=2531

caused regression of gdb testing of bfin-ucinux and bfin-linux-uclibc
toolchains.

Thanks,
Jie
Permalink | Reply | 2 comments |
headers
Robin Getz | 14 Feb 2007 05:42
Favicon

Re: sigaltstack obsoleted?

On Tue 13 Feb 2007 22:07, Zhang, Sonic wrote:
> Because the review comments from LKML said that we should remove this
> obsolete syscall.

I am not sure it is obsolete - maybe LKML was wrong?

I think it is still part of POSIX (IEEE Std 1003.1, 2004 Edition)
http://www.opengroup.org/onlinepubs/000095399/functions/sigaltstack.html

and all other distributions still define it:

asm-alpha/unistd.h:#define __NR_sigaltstack     235
asm-arm/unistd.h:#define __NR_sigaltstack               (__NR_SYSCALL_BASE+186)
asm-arm26/unistd.h:#define __NR_sigaltstack             (__NR_SYSCALL_BASE+186)
asm-avr32/unistd.h:#define __NR_sigaltstack     102
asm-blackfin/unistd.h:                          /* 186 __NR_sigaltstack obsolete */
asm-cris/unistd.h:#define __NR_sigaltstack      186
asm-frv/unistd.h:#define __NR_sigaltstack       186
asm-h8300/unistd.h:#define __NR_sigaltstack     186
asm-i386/unistd.h:#define __NR_sigaltstack      186
asm-ia64/unistd.h:#define __NR_sigaltstack              1176
asm-m32r/unistd.h:#define __NR_sigaltstack      186
asm-m68k/unistd.h:#define __NR_sigaltstack      186
asm-m68knommu/unistd.h:#define __NR_sigaltstack 186
asm-mips/unistd.h:#define __NR_sigaltstack              (__NR_Linux + 206)
asm-parisc/unistd.h:#define __NR_sigaltstack        (__NR_Linux + 166)
asm-powerpc/unistd.h:#define __NR_sigaltstack   185
asm-s390/unistd.h:#define __NR_sigaltstack        186
asm-sh/unistd.h:#define __NR_sigaltstack        186
asm-sh64/unistd.h:#define __NR_sigaltstack      186
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jie Zhang | 14 Feb 2007 08:33
Picon
Gravatar

Re: sigaltstack obsoleted?

On 2/14/07, Robin Getz <rgetz@...> wrote:
> On Tue 13 Feb 2007 22:07, Zhang, Sonic wrote:
> > Because the review comments from LKML said that we should remove this
> > obsolete syscall.
>
> I am not sure it is obsolete - maybe LKML was wrong?
>
Sonic has restored it. So now that gdb regression has been fixed.

Jie
Permalink | Reply | 0 comments |
headers
kang shuo | 15 Feb 2007 13:05
Picon

A question about head.S of bf537 kernel code

I found there is a line in head.S of bf537:
    call _real_start;
That seems a little different with head.S of bf533. According to my
understanding of head.S in bf537 , that seems from the above line ,
kernel jumps to _real_start. But in head.S of bf533, there is jump to
_real_start by raise 15.
Is there any guy can solve my confusion ?

- Thanks
- Michael.Kang

On 2/12/07, Jie Zhang <jzhang918@...> wrote:
> Now building latest uclinux-dist requires a toolchain built from
> latest linux kernel. Otherwise you will encounter building errors on
> usr/gdbserver, like:
>
> ../linux-bfin-low.c:29: error: 'PT_R0' undeclared here (not in a function)
> ../linux-bfin-low.c:29: error: 'PT_R1' undeclared here (not in a function)
> ../linux-bfin-low.c:29: error: 'PT_R2' undeclared here (not in a function)
> ../linux-bfin-low.c:29: error: 'PT_R3' undeclared here (not in a function)
> ../linux-bfin-low.c:29: error: 'PT_R4' undeclared here (not in a function)
> ../linux-bfin-low.c:29: error: 'PT_R5' undeclared here (not in a function)
> ...
>
>
> Jie
> _______________________________________________
> Uclinux-dist-devel mailing list
> Uclinux-dist-devel@...
> http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
(Continue reading)

Permalink | Reply | 501 comments |
headers
Bernd Schmidt | 15 Feb 2007 18:27
Picon
Favicon

Re: [toolchain-devel] Speed up divide by constant

Mike Frysinger wrote:
> On 2/8/07, Bernd Schmidt <bernds_cb1@...> wrote:
>> Mike Frysinger wrote:
>> > 
>> /usr/local/src/blackfin/toolchains/20070207/out-linux-uclibc/bin/bfin-linux-uclibc-ld: 
>>
>> >
>> > a.out: hidden symbol `___umulsi3_highpart' in
>> > 
>>
/usr/local/src/blackfin/toolchains/20070208/gcc_build-4.1/./gcc/libgcc.a(_umulsi3_highpart.o) 
>>
>>
>> Doesn't happen here.  This makes no sense - why is the symbol hidden in
>> your libgcc.a?  Do you have any local changes in gcc or binutils?
> 
> nope ... current svn trunk with no modifications
> 
> but it is a local problem of some sort ... building as root and it
> works; building as user and it fails

Did you figure out what was happening?  I'm seeing the same thing now 
with one of my builds.

Bernd
--

-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Frysinger | 16 Feb 2007 22:13
Picon

Re: A question about head.S of bf537 kernel code

On 2/15/07, kang shuo <blackfin.kang@...> wrote:
> I found there is a line in head.S of bf537:
>     call _real_start;
> That seems a little different with head.S of bf533. According to my
> understanding of head.S in bf537 , that seems from the above line ,
> kernel jumps to _real_start. But in head.S of bf533, there is jump to
> _real_start by raise 15.
> Is there any guy can solve my confusion ?

http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=2781
-mike
Permalink | Reply | 501 comments |
headers
Mike Frysinger | 19 Feb 2007 23:57
Picon

msync and no-mmu

uClibc does not define msync() if the arch does not include it in its
exported syscall table (aka, no __NR_msync in blackfin)

question is though, is this function expected to work without a MMU ?
-mike
Permalink | Reply | 2 comments |
headers
Bernd Schmidt | 20 Feb 2007 11:59
Picon
Favicon

Re: msync and no-mmu

Mike Frysinger wrote:
> uClibc does not define msync() if the arch does not include it in its
> exported syscall table (aka, no __NR_msync in blackfin)
> 
> question is though, is this function expected to work without a MMU ?

Wouldn't think so since you can't have non-private mappings anyway.

Bernd
--

-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough
Permalink | Reply | 1 comment |
headers
Mike Frysinger | 20 Feb 2007 16:33
Picon

Re: msync and no-mmu

On 2/20/07, Bernd Schmidt <bernds_cb1@...> wrote:
> Mike Frysinger wrote:
> > uClibc does not define msync() if the arch does not include it in its
> > exported syscall table (aka, no __NR_msync in blackfin)
> >
> > question is though, is this function expected to work without a MMU ?
>
> Wouldn't think so since you can't have non-private mappings anyway.

ok, i'll add a static inline func to the headers for no-mmu that
simply returns success
-mike
Permalink | Reply | 0 comments |
headers
Mike Frysinger | 21 Feb 2007 23:38
Picon

Re: Speed up divide by constant

On 2/15/07, Bernd Schmidt <bernds_cb1@...> wrote:
> Mike Frysinger wrote:
> > On 2/8/07, Bernd Schmidt <bernds_cb1@...> wrote:
> >> Mike Frysinger wrote:
> >> >
> >> /usr/local/src/blackfin/toolchains/20070207/out-linux-uclibc/bin/bfin-linux-uclibc-ld:
> >>
> >> >
> >> > a.out: hidden symbol `___umulsi3_highpart' in
> >> >
> >> /usr/local/src/blackfin/toolchains/20070208/gcc_build-4.1/./gcc/libgcc.a(_umulsi3_highpart.o)
> >>
> >>
> >> Doesn't happen here.  This makes no sense - why is the symbol hidden in
> >> your libgcc.a?  Do you have any local changes in gcc or binutils?
> >
> > nope ... current svn trunk with no modifications
> >
> > but it is a local problem of some sort ... building as root and it
> > works; building as user and it fails
>
> Did you figure out what was happening?  I'm seeing the same thing now
> with one of my builds.

i did not ... and i cant recreate the failure anymore with current trunk ...
-mike
Permalink | Reply | 0 comments |

Gmane