current recommended versions of glibc/egcs/binutils for R5?

current recommended versions of glibc/egcs/binutils for R5?

[R Shapiro]

What are the currently recommended *stable* versions of glibc, egcs
and binutils in R5?  Should I stick with the installed versions:

 glibc 2.1.1-6c, egcs 1.1.2-12c, binutils 2.9.1.0.990418-1c

or use the newer versions available on linuxppc.org:

 glibc 2.1.2-1a, egcs 1.1.2-12f, binutils-2.9.4.0.8-1a

or some other versions?  I'm looking for stability here, not the
latest experimental releases.



-- 
reshapiro@mediaone.net
rshapiro@bbn.com

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: current recommended versions of glibc/egcs/binutils for R5?

[Franz Sirl]

Am Son, 01 Aug 1999 schrieb R Shapiro:
>What are the currently recommended *stable* versions of glibc, egcs
>and binutils in R5?  Should I stick with the installed versions:
>
> glibc 2.1.1-6c, egcs 1.1.2-12c, binutils 2.9.1.0.990418-1c
>
>or use the newer versions available on linuxppc.org:
>
> glibc 2.1.2-1a, egcs 1.1.2-12f, binutils-2.9.4.0.8-1a

I consider the newer versions stable and told the distribution maintainers
about it.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

gdb broken under linuxppc r5 tools

[Kevin B. Hendricks]

Hey,

Does anyone know what's up with gdb lately?  It used to be quite stable but
since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
can't seem to set any breakpoints in shared libraries (or they show up
someplace else at random).  Functions are missing (or don't show up) and if
I try to disassemble one function in a shared library, I often get another.

I really need a working stable gdb.

Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
binutils, egcs are stable together, especially when working with shared
libraries?

Thanks,

Kevin




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[Franz Sirl]

Am Son, 01 Aug 1999 schrieb Kevin B. Hendricks:
>Hey,
>
>Does anyone know what's up with gdb lately?  It used to be quite stable but
>since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
>can't seem to set any breakpoints in shared libraries (or they show up
>someplace else at random).  Functions are missing (or don't show up) and if
>I try to disassemble one function in a shared library, I often get another.
>
>I really need a working stable gdb.
>
>Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
>binutils, egcs are stable together, especially when working with shared
>libraries?

Well, you've hit one of our weakest points here. AFAIK there's currently nobody
taking care of gdb on Linux/PPC. In fact we are lucky that Kevin Buettner's old
patch could be converted to 4.17.x. Unfortunately it's still not integrated
into gdb's mainline due to copyright issues, so we have to reintegrate the patch
in every new version :-(.

So, is someone willing to take care of gdb on Linux/PPC?

Kevin, as a first measure, do you pass LD_BIND_NOW=1 in the environment?

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[kbhend]

On Sun, 01 Aug 1999, Franz Sirl wrote:
>
> Kevin, as a first measure, do you pass LD_BIND_NOW=1 in the environment?
> 
> Franz.

Yes, that is the default we set with the jdk.  Unfortunately it is no help.
Could this be kernel related?  I saw this problem with some of Paul's kernels
under R4 and then all problems with gdb went away.  Everything worked fine
under YDL but since my upgrade to LinuxPPC R5 and Paul's 2.2.10 kernel, the old
problems have re-appeared.

It is like some piece of cache is not being properly flushed.

By the way, I noticed from disassembling some code from egcs 1.1.2-12c that the
stwu instruction is being used again.  I thought Gary Thomas patched the egcs
source to prevent stwu from being generated becuase of some serious problems
with it being used in certain combinations on 604e systems.  Any info on this?

Thanks,

Kevin

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[Kevin Buettner]

On Aug 1,  9:03pm, Franz Sirl wrote:

> Am Son, 01 Aug 1999 schrieb Kevin B. Hendricks:
> >Hey,
> >
> >Does anyone know what's up with gdb lately?  It used to be quite stable but
> >since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
> >can't seem to set any breakpoints in shared libraries (or they show up
> >someplace else at random).  Functions are missing (or don't show up) and if
> >I try to disassemble one function in a shared library, I often get another.
> >
> >I really need a working stable gdb.
> >
> >Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
> >binutils, egcs are stable together, especially when working with shared
> >libraries?
> 
> Well, you've hit one of our weakest points here. AFAIK there's currently nobody
> taking care of gdb on Linux/PPC. In fact we are lucky that Kevin Buettner's old
> patch could be converted to 4.17.x. Unfortunately it's still not integrated
> into gdb's mainline due to copyright issues, so we have to reintegrate the patch
> in every new version :-(.
> 
> So, is someone willing to take care of gdb on Linux/PPC?

Kevin, Franz, et.al,

Earlier this year, Metrowerks and I signed the copyright assignments
required by the FSF.  Beginning August 9, I will be starting work at
Cygnus as a GDB engineer.  One of the things that I'll work on is a
merge of my patches into the current gdb mainline.  It'll be my goal
to get a solid, usable gdb up and running on Linux/PPC again.

Kevin

-- 
Kevin Buettner
kev@primenet.com

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[Franz Sirl]

Am Son, 01 Aug 1999 schrieb Kevin Buettner:
>Kevin, Franz, et.al,
>
>Earlier this year, Metrowerks and I signed the copyright assignments
>required by the FSF.  Beginning August 9, I will be starting work at
>Cygnus as a GDB engineer.  One of the things that I'll work on is a
>merge of my patches into the current gdb mainline.  It'll be my goal
>to get a solid, usable gdb up and running on Linux/PPC again.

Wow, that are really great news! Congrats!

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[Gary Thomas]

On 01-Aug-99 Kevin Buettner wrote:
> 
> On Aug 1,  9:03pm, Franz Sirl wrote:
> 
>> Am Son, 01 Aug 1999 schrieb Kevin B. Hendricks:
>> >Hey,
>> >
>> >Does anyone know what's up with gdb lately?  It used to be quite stable but
>> >since I upgraded to the glibc, binutils, egcs, gdb from Linuxppc R5 cd, I
>> >can't seem to set any breakpoints in shared libraries (or they show up
>> >someplace else at random).  Functions are missing (or don't show up) and if
>> >I try to disassemble one function in a shared library, I often get another.
>> >
>> >I really need a working stable gdb.
>> >
>> >Has anyone else run into this.  If so, exactly what versions of gdb, glibc,
>> >binutils, egcs are stable together, especially when working with shared
>> >libraries?
>> 
>> Well, you've hit one of our weakest points here. AFAIK there's currently
>> nobody
>> taking care of gdb on Linux/PPC. In fact we are lucky that Kevin Buettner's
>> old
>> patch could be converted to 4.17.x. Unfortunately it's still not integrated
>> into gdb's mainline due to copyright issues, so we have to reintegrate the
>> patch
>> in every new version :-(.
>> 
>> So, is someone willing to take care of gdb on Linux/PPC?
> 
> Kevin, Franz, et.al,
> 
> Earlier this year, Metrowerks and I signed the copyright assignments
> required by the FSF.  Beginning August 9, I will be starting work at
> Cygnus as a GDB engineer.  One of the things that I'll work on is a
> merge of my patches into the current gdb mainline.  It'll be my goal
> to get a solid, usable gdb up and running on Linux/PPC again.
> 

Kevin B.,

Firstly, congratulations and welcome to the fold :-)

Secondly, while you're in there, can you look at my patches for GDB-4.18.
I've made a useable GDB for this version, with no input from any of the
4.17 patches BTW.  They might be easier to make into a "clean" set for
the latest version.  You can find my patches in the RPM I uploaded to
  ftp://ftp.linuxppc.org/users/gdt/redhat/SRPMS

When you get something ready, let me know and I'll help check it out.

Thanks.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[kbhend]

Hi Kevin,

> Kevin, Franz, et.al,
> 
> Earlier this year, Metrowerks and I signed the copyright assignments
> required by the FSF.  Beginning August 9, I will be starting work at
> Cygnus as a GDB engineer.  One of the things that I'll work on is a
> merge of my patches into the current gdb mainline.  It'll be my goal
> to get a solid, usable gdb up and running on Linux/PPC again.

Congrats!  It is good to hear from you again!  We still miss you on the LinuxPPC
JDK porting team!  Care to rejoin?!? :-)

As for gdb, something changed seriously between Paul's 2.2.1 kernel running on
a R4.1 build (gdb was very very stable when debugging shared libs) and Paul's
2.2.10 kernel running LinuxPPC R5 or YDL.

I tried Gary's 4.18 src rpm and it rebuilt fine under R5 but shows exactly the
same error mode as the 4.17 builds.  I will put a breakpoint at a function in a
shared lib (such as awt_allocate_colors in libawt.so) and the function address
returned by gdb when it says it places the breakpoint is typically not a valid
address (typically something in 0x00XXXXXX or 0x0XXXXXXX range).  
Sometimes it ends up putting the breakpoint into another routine (often glibc)
which you can see if luckily your code uses that other shared lib.

This is so frustrating.  If I can find (by chance) the actual location of the
shared lib routine (by disassmebling large pieces of memory) and use the exact
address to place the breakpoint, it will actually stop there.

Some change to the debugging symbols must have been made to cause this I think,
but I am not sure.

Anyway, I hope you can recreate these problems and can find a solution!!!!

Thanks,

Kevin H.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[Daniel Jacobowitz]

On Mon, Aug 02, 1999 at 11:21:19AM -0400, kbhend wrote:
> 
> Hi Kevin,
> 
> > Kevin, Franz, et.al,
> > 
> > Earlier this year, Metrowerks and I signed the copyright assignments
> > required by the FSF.  Beginning August 9, I will be starting work at
> > Cygnus as a GDB engineer.  One of the things that I'll work on is a
> > merge of my patches into the current gdb mainline.  It'll be my goal
> > to get a solid, usable gdb up and running on Linux/PPC again.
> 
> Congrats!  It is good to hear from you again!  We still miss you on the LinuxPPC
> JDK porting team!  Care to rejoin?!? :-)
> 
> As for gdb, something changed seriously between Paul's 2.2.1 kernel running on
> a R4.1 build (gdb was very very stable when debugging shared libs) and Paul's
> 2.2.10 kernel running LinuxPPC R5 or YDL.

Could you possibly try booting 2.2.1 on this R5 or YDL system?  I'd
like to isolate this from kernel or userland problem.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: gdb broken under linuxppc r5 tools

[kbhend]

Hi Kevin,

In case this helps, here is a snippet of my frustrating gdb session:

Here is some sample output from gdb if it helps:

(gdb) list awt_allocate_colors
823                 awt_data->color_data->awt_icmLUT
824                             [awt_data->color_data->awt_numICMcolors++] = 0xff000000;
825             }
826         }
827         return 1;
828     }
829
830     #define red(v)          (((v) >> 16) & 0xFF)
831     #define green(v)        (((v) >>  8) & 0xFF)
832     #define blue(v)         (((v) >>  0) & 0xFF)
(gdb) # this is not the right place
(gdb) print awt_allocate_colors
$7 = {int (AwtData *)} 0xf46500 <awt_post_java_mouse_event+1056>
(gdb) # 0xf46500 is not the right address
(gdb) b awt_allocate_colors
Breakpoint 1 at 0xf46500: file ../../../../src/linux/native/sun/awt/color.c, line 828.
(gdb) # this coincides with the source shown above
(gdb) # but now look what I found from running x/20i repeatedly
(gdb) x/10i
0xf4728c 0xf4728c <awt_allocate_colors>: stwu    r1,-5280(r1)
0xf47290 <awt_allocate_colors+4>:       mflr    r0
0xf47294 <awt_allocate_colors+8>:       stw     r30,5272(r1)
0xf47298 <awt_allocate_colors+12>:      stw     r31,5276(r1)
0xf4729c <awt_allocate_colors+16>:      stw     r0,5284(r1)
0xf472a0 <awt_allocate_colors+20>:      mr      r31,r1
0xf472a4 <awt_allocate_colors+24>:
    bl  0xf472a8 <awt_allocate_colors+28>
0xf472a8 <awt_allocate_colors+28>:      mflr    r30
0xf472ac <awt_allocate_colors+32>:      lwz     r0,-32(r30)
0xf472b0 <awt_allocate_colors+36>:      add     r30,r0,r30
(gdb) # this is the true beginning of awt_allocate_colors at 0xf4728c
(gdb) # so part of gdb knows 0xf4728c is awt_allocate_colors
(gdb) # but another part thinks it is at 0xf46500
(gdb) # here is something else funny
(gdb) b awt_color_match
Note: breakpoint 1 also set at pc 0xf46500.
Breakpoint 2 at 0xf46500: file ../../../../src/linux/native/sun/awt/color.c, line 828.
(gdb) print awt_color_match
$8 = {int (int, int, int, AwtData *)} 0xf46500 <awt_post_java_mouse_event+1056>
(gdb) # awt_color_match is a completely different routine but
(gdb) # gdb has mapped it to the infamous 0xf46500
(gdb) # aaaarrrggghhhh!
(gdb)

This only seems to happen in shared libraries.  Breakpoints at main in the main
routine work fine.

So gdb is completely unusable as it is when debugging shared libs.  It seems to
map many different routines to the same address.   I hope this snippet helps.

Kevin H.



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

bug in glibc 2.1.2 new semaphore functions in libpthread?

[Kevin Hendricks]

Hi,

Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads? 

If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
sem_post@@GLIBC_2.0, etc, they work fine. 

If I link the native threads version of the jdk with the new semaphore
functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.

I found this out because I had two binariies from the same source, one of which
works and the other doesn't and the only difference was that the first (working
one) was built under an earlier glibc 2.1 while the latter was built with
Franz's latest glibc 2.1.2.

Upon further investigation with nm I found  that the only difference was in
which semaphore functions got linked in from libpthread.so.

If it matters, this is in a high signal environment (thread interrupts, thread
suspension for garabage collection, etc).

I had to drop back to glibc 2.1.1 and rebuild to get the
native_threads to start working again (so that they would link with the old
sem_* functions and not the new).

Has anyone really tested the new semaphore functions?  Are they known to be
broken?  

Any ideas here?

Thanks,

Kevin


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: bug in glibc 2.1.2 new semaphore functions in libpthread?

[Franz Sirl]

Am Son, 22 Aug 1999 schrieb Kevin Hendricks:
>Hi,
>
>Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads? 
>
>If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
>sem_post@@GLIBC_2.0, etc, they work fine. 
>
>If I link the native threads version of the jdk with the new semaphore
>functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.
>
>I found this out because I had two binariies from the same source, one of which
>works and the other doesn't and the only difference was that the first (working
>one) was built under an earlier glibc 2.1 while the latter was built with
>Franz's latest glibc 2.1.2.
>
>Upon further investigation with nm I found  that the only difference was in
>which semaphore functions got linked in from libpthread.so.
>
>If it matters, this is in a high signal environment (thread interrupts, thread
>suspension for garabage collection, etc).
>
>I had to drop back to glibc 2.1.1 and rebuild to get the
>native_threads to start working again (so that they would link with the old
>sem_* functions and not the new).
>
>Has anyone really tested the new semaphore functions?  Are they known to be
>broken?  
>
>Any ideas here?

Kevin, the glibc-2.1.2 RPM's are work-in-progress. They generally work well for
me and others, but it may very well be that things are temporarily broken.
Please test the new 4a build. If your problem persists I'll forward it to the
glibc maintainers.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]