[commit] Some stray IN_SOLIB_CALL_TRAMPOLINE macros

Just FYI, another #define and #undef.  Again removed.
Andrew

2004-10-31  Andrew Cagney  <cagney <at> gnu.org>

	* config/pa/tm-linux.h: Delete #undef IN_SOLIB_CALL_TRAMPOLINE.
	* config/tm-sysv4.h (IN_SOLIB_CALL_TRAMPOLINE): Delete.
	(in_plt_section): Delete.

Index: config/tm-sysv4.h
===================================================================
RCS file: /cvs/src/src/gdb/config/tm-sysv4.h,v
retrieving revision 1.4
diff -p -u -r1.4 tm-sysv4.h
--- config/tm-sysv4.h	11 Oct 2002 14:02:38 -0000	1.4
+++ config/tm-sysv4.h	31 Oct 2004 23:59:53 -0000
 <at>  <at>  -20,17 +20,6  <at>  <at> 
    Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */

-/* For SVR4 shared libraries, each call to a library routine goes through
-   a small piece of trampoline code in the ".plt" section.
-   The horribly ugly wait_for_inferior() routine uses this macro to detect
-   when we have stepped into one of these fragments.
-   We do not use lookup_solib_trampoline_symbol_by_pc, because
-   we cannot always find the shared library trampoline symbols
-   (e.g. on Irix5).  */
-
-#define IN_SOLIB_CALL_TRAMPOLINE(pc, name) in_plt_section((pc), (name))

Re: [COMMIT] OpenBSD/mips64 target and native support

Mark Kettenis wrote:
>    Date: Sun, 31 Oct 2004 15:07:16 -0500
>    From: Andrew Cagney <cagney <at> gnu.org>
> 
>    > Scaring away contributors by making unreasonable demands isn't a
>    > sensible thing to do.
> 
>    Our situtation here is identical to what we encountered with basic 
>    multi-arch, the frame code, the regcace code, the function call code. 
>    There, with our help and co-operation, people not just stepped up to, 
>    but also exceeded the challenge.
> 
> I strongly disagree.  The shared library code touches core parts of
> GDB.  There's no way an outsider is going to be able to fix that
> properly, especially since changes will have to be tested on a
> multitude of platforms.  There is also absolutely no visible benefit
> from making the required changes.  This is something the shared
> library maintainer and core maintainers have to sort out.  It's going
> to take quite a bit of time to do so.

Blank [puzzled] expression.

This code is generic.
We already have optional svr4 shlibs working.
All our key platforms are svr4.
We've never required testing across a ``multitude of platforms''.
We strongly encourage cleanups.

So what's so hard about this?  Especially when, the core maintainers 
will be helping with the task.

[RFA/m32r] Unreviewed patch (breakpoint bug)

This is the third ping. It has been three weeks since I posted the
following patch...
Would anyone review it?

Kei Sakamoto

From: "Kei Sakamoto" <sakamoto.kei <at> renesas.com>
To: <gdb-patches <at> sources.redhat.com>
Sent: Monday, October 25, 2004 6:03 PM
Subject: [RFA/m32r] Unreviewed patch (breakpoint bug)

> This is the second ping.
> Please review the following patch.
> 
> Kei Sakamoto
> 
> From: "Kei Sakamoto" <sakamoto.kei <at> renesas.com>
> To: <gdb-patches <at> sources.redhat.com>
> Sent: Monday, October 18, 2004 3:43 PM
> Subject: [RFA/m32r] Unreviewed patch (breakpoint bug)
> 
> > Hello,
> > 
> > Would anyone review this patch?
> > Thank you in advance.
> > 
> > Kei Sakamoto
> > 
> > From: "Kei Sakamoto" <sakamoto.kei <at> renesas.com>
> > To: <gdb-patches <at> sources.redhat.com>

: Re: [RFA] Setting long long bitfields

Oops, sorry: I got the problematic case backwards.  The problem is
that a bitsize of 0 is legal, and that causes the result of your 
suggested tweak to be officially undefined.

Paul

>  > > One possible tweak, several of us have an aversion to "?:", it would be
>  > > nice if it wasn't there 
>  > 
>  > Like this perhaps:
>  > 
>  > +  ULONGEST mask = (ULONGEST) -1 >> (8 * sizeof (ULONGEST) - bitsize);
> 
> Andreas,
> 
> I had considered exactly that line, but unfortunately ran across the
> following really irritating provision in the C standard:
> 
>     "If the value of the right operand is negative or is 
>      *greater than or equal to* the width of the promoted left
>      operand, the behavior is undefined."
> 
> [I know why the provision is there, of course: many machines treat a
> shift of wordsize bits as 0, because they mask off bits to the left,
> but it's STILL irritating.]
> 
> Now, I presume we will never encounter a bitfield size of 8 * sizeof
> (ULONGEST), but the original code apparently tried to bullet-proof
> against this possibility, so I just went along.

Re: [RFA] Setting long long bitfields

Paul Hilfinger <hilfingr <at> EECS.Berkeley.EDU> writes:

>  > > One possible tweak, several of us have an aversion to "?:", it would be
>  > > nice if it wasn't there 
>  > 
>  > Like this perhaps:
>  > 
>  > +  ULONGEST mask = (ULONGEST) -1 >> (8 * sizeof (ULONGEST) - bitsize);
>
> Andreas,
>
> I had considered exactly that line, but unfortunately ran across the
> following really irritating provision in the C standard:
>
>     "If the value of the right operand is negative or is 
>      *greater than or equal to* the width of the promoted left
>      operand, the behavior is undefined."

That cannot happen, because bitsize will never be zero.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: : Re: [RFA] Setting long long bitfields

Paul Hilfinger <hilfingr <at> EECS.Berkeley.EDU> writes:

> Oops, sorry: I got the problematic case backwards.  The problem is
> that a bitsize of 0 is legal, and that causes the result of your 
> suggested tweak to be officially undefined.

How can bitsize ever become zero?  Note that the original code contains a
shift by bitsize - 1, which is undefined as well in this case.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: backtrace changes current source location

ok, here's a new patch and testcase.  built and tested on
i686-pc-linux-gnu.  the testcase adds 7 PASS and 1 FAIL, which
becomes 8 PASS with the patch.

gdb/ChangeLog
2004-10-31  Felix Lee  <felix+log1 <at> specifixinc.com>

        * stack.c (set_current_sal_from_frame): New function.
        (print_args_stub): Use it.
        (print_frame_info): Don't set sal here.

gdb/testsuite/ChangeLog
2004-10-31  Felix Lee  <felix+log1 <at> specifixinc.com>

        * gdb.base/cursal.exp: New file.
        * gdb.base/cursal.c: New file.

Index: gdb/stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.115
diff -p -u -r1.115 stack.c
--- gdb/stack.c	30 Oct 2004 21:16:10 -0000	1.115
+++ gdb/stack.c	31 Oct 2004 10:42:55 -0000
 <at>  <at>  -100,6 +100,8  <at>  <at>  static void print_frame (struct frame_in
 			 int print_args, 
 			 struct symtab_and_line sal);

+static void set_current_sal_from_frame (struct frame_info *, int);
+

Re: [commit] Add add_setshow_enum_cmd, use in mips

> Date: Sun, 31 Oct 2004 18:01:30 -0500
> From: Andrew Cagney <cagney <at> gnu.org>
> Cc: gdb-patches <at> sources.redhat.com
> 
> The missing add_setshow_enum_cmd both goes with, and is consistent, with 
> the existing add_setshow zinteger, boolean, auto_boolean, filename, 
> string, uinteger command functions

I didn't say the patch was unreasonable, just that it should have been
an RFA, since it is by no means ``obvious''.

What about documenting the function?

Re: [commit] Add add_setshow_enum_cmd, use in mips

On Mon, Nov 01, 2004 at 06:41:12AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 31 Oct 2004 18:01:30 -0500
> > From: Andrew Cagney <cagney <at> gnu.org>
> > Cc: gdb-patches <at> sources.redhat.com
> > 
> > The missing add_setshow_enum_cmd both goes with, and is consistent, with 
> > the existing add_setshow zinteger, boolean, auto_boolean, filename, 
> > string, uinteger command functions
> 
> I didn't say the patch was unreasonable, just that it should have been
> an RFA, since it is by no means ``obvious''.

Why?  There is no maintainer for this area, and Andrew is entitled to
approve patches himself, so an RFA (request for approval) seems
unnecessary.

--

-- 
Daniel Jacobowitz

Re: [RFA] Setting long long bitfields

> How can bitsize ever become zero?  Note that the original code contains a
> shift by bitsize - 1, which is undefined as well in this case.

Actually, Ada programs, unlike C, can generate fields of width 0.  I see,
however, that (somewhat accidentally) that case is handled as a 0-byte
ordinary byte-aligned field (where the alignment doesn't matter, of course,
since 0 bytes of data are modified).  Very well, I will adopt Andreas'
suggestion, and also document the precondition in the comment.  

Thanks.

Paul