headers
Kenny Simpson | 1 Dec 2005 08:55
Picon
Favicon

re: posix semaphores not working under gdb

One thing that caused me some pain a while ago is the semaphore behavioral change in NPTL vs
LinuxThreads.  Under LinuxThreads, sem_wait will never return until the semaphore is aquired. 
With NPTL, sem_wait can return EINTR
... and DOES when gdb attaches.

The man pages in many distrubutions still have the old LinuxThreads documentation which explictly
states that sem_wait will not be affected by signals.

Hope this helps...
-Kenny

	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
Permalink | Reply | 501 comments |
headers
Daniel Juan | 1 Dec 2005 14:15
Picon

Re: posix semaphores not working under gdb

You are right Kenny,

if you look at the doc in NTPL:

man 3p sem_wait

The  sem_trywait()  and sem_wait() functions shall return zero if the
calling process successfully performed the semaphore lock operation on
the semaphore designated by sem.If the call was unsuccessful, the
state of the semaphore shall be unchanged, and the function shall
return a value of -1 and set errno to indicate the error.

If you look at Linuxthreads

man 3 sem_wait

The sem_wait and sem_getvalue functions always return 0.

Thanks

On 12/1/05, Kenny Simpson <theonetruekenny <at> yahoo.com> wrote:
> One thing that caused me some pain a while ago is the semaphore behavioral change in NPTL vs
> LinuxThreads.  Under LinuxThreads, sem_wait will never return until the semaphore is aquired.
> With NPTL, sem_wait can return EINTR
> ... and DOES when gdb attaches.
>
> The man pages in many distrubutions still have the old LinuxThreads documentation which explictly
> states that sem_wait will not be affected by signals.
>
> Hope this helps...
(Continue reading)

Permalink | Reply | 501 comments |
headers
Hans-Peter Nilsson | 1 Dec 2005 18:20
Picon
Favicon

RFC: common simulator cycle output option

It seems that few simulators (I only know of one ;-) have an
option to output cycle count or other measurement of execution
time other than wallclock time spent in the simulator.  This
poses a problem with cross-testing code quality like in GCC
regression tests.

I'd like to introduce a general option suggesting
--generic-cycle-count[=FILE] to output something like
"Cycle-count: %lld\n" on FILE, default stderr.  The output
doesn't *have* to include all cycles (if the simulator port
doesn't account for some cycles, for example memory accesses)
and may be off linearly (by a constant and a factor), but should
be repeatable (between hosts) and monotonously increasing with
execution time.  Wallclock is not a repeatable measurement and
is too coarse.

I know "-v" outputs an instruction count on *some*
architectures.  For CRIS (which has more detailed cycle-count
options), it outputs something like:
"run 20010122-1.x2
Simulator Execution Speed

  Total instructions:      2,143
  Total execution time:    < 1 second
"
where the comma poses problems using a single regex field for
the number.  Also, at least mips-sim doesn't output the "Total
instructions:" line (insn count isn't incremented from 0).  I'm
not sure the comma can be freely removed, but that might be an
option.  Still, I want the output to be cycles, not just
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Blandy | 2 Dec 2005 00:32
Favicon

Re: posix semaphores not working under gdb

Interesting: POSIX says, of thread_mutex_lock ( ),
pthread_mutex_trylock ( ), and pthread_mutex_unlock ( ):

34138      These functions shall not return an error code of [EINTR].

But of sem_wait ():
39299            The sem_trywait ( ) and sem_wait ( ) functions may fail if:
...
39301            [EINTR]             A signal interrupted this function.
Permalink | Reply | 0 comments |
headers
Kei Sakamoto | 2 Dec 2005 10:46

h8300 is removed?

Hello,

In gdb 6.4's NEWS file, h8300 is described as REMOVED.

> * REMOVED configurations and files
>
> VxWorks and the XDR protocol		*-*-vxworks
> Renesas H8/300S			h8300*-*-*

I think that h8300 was once removed but restored after
that.

Is NEWS file wrong? Or h8300 is really removed?

Kei Sakamoto
Permalink | Reply | 501 comments |
headers
Andrew STUBBS | 2 Dec 2005 19:22

[RFC] plugin/extension interface

Hi all,

I would like to test the waters and find out what your opinion would be 
on the subject of a GDB plugin/extension interface.

We, here at ST, have a custom target backend which is implemented as a 
DLL connected to some custom code in GDB not totally unlike remote.c. We 
did this because the remote protocol was too slow, too limited and 
required some way to launch other processes which could then easily get 
left over by mistake.

Now we have reason to rewrite the interface - it is currently very 
SH-centric and we wish to share it with another ST architecture - so I 
am considering the various possibilities.

One possibility (of which I am in favour) is to create a generic GDB 
plugin interface which can become part of the official GDB. This course 
of action is not yet certain, but the outcome of any discussion we have 
here will probably influence the final decision (along with some other 
local considerations).

Desirable features (from our point of view):
- Target independent [1].
- Architecture independent [1].
- Flexible/Powerful enough not to limit capabilities.
- Debugger independent [2].
- Extensible.
- Easy to maintain.

It is largely this last requirement which prompts me to ask your opinion
(Continue reading)

Permalink | Reply | 30 comments |
headers
Eli Zaretskii | 2 Dec 2005 19:48
Picon

Re: [RFC] plugin/extension interface

> Date: Fri, 02 Dec 2005 18:22:54 +0000
> From: Andrew STUBBS <andrew.stubbs <at> st.com>
> 
> I would like to test the waters and find out what your opinion would be 
> on the subject of a GDB plugin/extension interface.

Such suggestions (not only for GDB, for other GNU projects as well)
are usually rejected by Richard Stallman and the FSF, because they
make it possible to add to GDB significant new features with
proprietary (i.e. non-free software) shared libraries, thus avoiding
the need to release any parts of GDB under GPL.
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 2 Dec 2005 20:23

Re: [RFC] plugin/extension interface

On Fri, Dec 02, 2005 at 08:48:58PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 02 Dec 2005 18:22:54 +0000
> > From: Andrew STUBBS <andrew.stubbs <at> st.com>
> > 
> > I would like to test the waters and find out what your opinion would be 
> > on the subject of a GDB plugin/extension interface.
> 
> Such suggestions (not only for GDB, for other GNU projects as well)
> are usually rejected by Richard Stallman and the FSF, because they
> make it possible to add to GDB significant new features with
> proprietary (i.e. non-free software) shared libraries, thus avoiding
> the need to release any parts of GDB under GPL.

I think we could discuss this with the FSF, if we had sufficiently
compelling reasons.  But, I don't think that we do, right now.

Andrew, I can't support an interface like the one you've described.
GDB is a hugely complicated program, with many independent areas; it's
not clear to me which of those areas you're trying to make pluggable. 
It looks to me like it is specifically the target interface - just a
very small piece of the pie.  Also, new CLI commands.

If that's right, the traditional solution to the target interface is a
third party program which acts as a conversion tool between the GDB
remote protocol and your proprietary target protocol, with whatever
glue logic you would otherwise put into the plugin.  The remote
protocol serves as the boundary interface in the same way that the DLL
boundary would serve as an interface.

If what you want can't be done that way because of shortcomings in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Kettenis | 2 Dec 2005 20:36
Picon
Picon
Favicon

Re: [RFC] plugin/extension interface

> Date: Fri, 02 Dec 2005 18:22:54 +0000
> From: Andrew STUBBS <andrew.stubbs <at> st.com>
> 
> Hi all,
> 
> I would like to test the waters and find out what your opinion would be 
> on the subject of a GDB plugin/extension interface.

My initial reaction (without reading the rest of your mail) would be
"Not over my dead body!".  In my experience plugin/extension
interfaces add a lot of bloat, are difficult to maintain, and
difficult to support.  Look at the problems we've had with the
libthread-db.so stuff on Linux and (to a lesser extent) Solaris.
There are also GPL issues.

> We, here at ST, have a custom target backend which is implemented as a 
> DLL connected to some custom code in GDB not totally unlike remote.c. We 
> did this because the remote protocol was too slow, too limited and 
> required some way to launch other processes which could then easily get 
> left over by mistake.
> 
> Now we have reason to rewrite the interface - it is currently very 
> SH-centric and we wish to share it with another ST architecture - so I 
> am considering the various possibilities.
> 
> One possibility (of which I am in favour) is to create a generic GDB 
> plugin interface which can become part of the official GDB. This course 
> of action is not yet certain, but the outcome of any discussion we have 
> here will probably influence the final decision (along with some other 
> local considerations).
(Continue reading)

Permalink | Reply | 25 comments |
headers
Jim Blandy | 2 Dec 2005 23:12
Favicon

Re: [RFC] plugin/extension interface

I'm not so hostile to plug-in interfaces.  It's true that the API
needs to be designed carefully, but allowing people to maintain other
features (targets; architectures; commands) separately from GDB would
take a big load off our backs.

It's true that plugin interfaces weaken the incentives the GPL tries
to create, but while I think that was very important even five years
ago, I don't think that's such a big deal any more.  Maybe I don't get
out enough, but I think there's already a consensus building that Open
Source is simply the preferable way to develop programmers' tools, and
most companies are just doing it freely, not because they have to use
GPL'd ode.

libthread_db has been a debacle, but I'd argue that's because it was
designed for Solaris, and we lacked the option of adjusting the
interface to better suit other systems.  For example, the API doesn't
abstract the process of stopping or continuing threads, meaning that
it doesn't have the information it needs to cache things accurately in
some cases (leading to bad performance) and that GDB pays the price in
complexity of supporting the plugin interface, but ends up knowing a
lot about the thread implementation anyway, so it doesn't get much
benefit.
Permalink | Reply | 24 comments |

Gmane