Re: alloca is bad?

[Andrew Cagney <ac131313@cygnus.com>]

Nick Duffek wrote:
> 
> On 9-Nov-2000, Christopher Faylor wrote:
> 
> >I've been told in private email that I mustn't use alloca
> 
> Say it ain't so!
> 
> >Alloca is useful.
> 
> Especially because multi-arching is turning small compile-time constants
> into run-time variables all over the place.  If we can't use alloca, then
> wherever there's something like this:
> 
>   char rawbuf[MAX_REGISTER_SIZE];

This is being converted to

	char *rawbuf = alloca (MAX_REGISTER_SIZE);

with the knowledge that it probably isn't going to work on some hosts. 
The conversion is tolerated because a more significant change incures
greater risk (bigger chance of someone botching it :-).

At the time it was agreed that such alloca() calls should eventually be
eliminated.

	Andrew
From cgf@cygnus.com Thu Nov 09 22:20:00 2000
From: "Christopher G. Faylor" <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Thu, 09 Nov 2000 22:20:00 -0000
Message-id: <20001110012016.A18577@redhat.com>
References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com>
X-SW-Source: 2000-11/msg00059.html
Content-length: 865

On Fri, Nov 10, 2000 at 05:11:55PM +1100, Andrew Cagney wrote:
>Nick Duffek wrote:
>> 
>> On 9-Nov-2000, Christopher Faylor wrote:
>> 
>> >I've been told in private email that I mustn't use alloca
>> 
>> Say it ain't so!
>> 
>> >Alloca is useful.
>> 
>> Especially because multi-arching is turning small compile-time constants
>> into run-time variables all over the place.  If we can't use alloca, then
>> wherever there's something like this:
>> 
>>   char rawbuf[MAX_REGISTER_SIZE];
>
>This is being converted to
>
>	char *rawbuf = alloca (MAX_REGISTER_SIZE);
>
>with the knowledge that it probably isn't going to work on some hosts. 
>The conversion is tolerated because a more significant change incures
>greater risk (bigger chance of someone botching it :-).
>
>At the time it was agreed that such alloca() calls should eventually be
>eliminated.

Why?

cgf
From ac131313@cygnus.com Thu Nov 09 22:27:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Thu, 09 Nov 2000 22:27:00 -0000
Message-id: <3A0B93BE.C434189D@cygnus.com>
References: <20001109212032.A26464@redhat.com>
X-SW-Source: 2000-11/msg00060.html
Content-length: 1639

Christopher Faylor wrote:
> 
> A patch that I recently submitted to gdb-patches used the alloca ()
> function to allocate memory.  I've been told in private email that I
> mustn't use alloca because "stack corruption problems are harder to
> debug" than heap corruption problems.

The principal reason is that it is non-portable. Some hosts have fairly
arbitrary limits on how much can be alloca()'d.  A black/white please
don't use this is easier to follow than some vague ``only when''
guideline .... Yes, multi-arch has put us into the grey.

Other secondary factors in the decision would have included the
observation that alloca (and stack arrays) (well actually just C :-) can
lead to nasy buffer overflow bugs that corrupt the stack.

	Andrew


> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?
> 
> It is my assertion that the amount of bookkeeping and overhead required
> to use malloc in a way that is analogous with alloca essentially
> nullifies the "harder to debug" argument.  malloc requires a free and
> many times, in gdb context, the only way to guarantee a free is with the
> use of the cleanup function.  Any time you add the complexity of
> something like 'cleanup()' (or whatever other mechanism you use to
> ensure that what you malloc is automatically freed) you can't claim to
> have reduced debugging problems.  Speaking of free, with alloca you
> don't have memory leaks.  With malloc, you do.
> 
> If alloca is bad, then why are local arrays and pointers to local
> variables and parameters ok?
> 
> Inquiring minds...
> 
> cgf
From eliz@delorie.com Fri Nov 10 02:39:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: bstell@netscape.com
Cc: gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 02:39:00 -0000
Message-id: <200011101039.FAA29785@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com>
X-SW-Source: 2000-11/msg00061.html
Content-length: 636

> Date: Thu, 09 Nov 2000 16:59:49 -0800
> From: bstell@netscape.com (Brian Stell)
> 
> The strings could be UTF-8, UTF-16, some kind
> of C++ object, etc.
> 
> What provision is there for Gdb users to extend
> Gdb to display an application specific item like
> this?

One way is to call the functions in the debuggee that convert these
strings to a printable representation, then print the result; the GDB
command "print" can do that.  It is highly likely that in a program
which supports non-ASCII characters you will have functions which
convert non-ASCII strings to a printable representation and back.

Does that solve the problem?
From eliz@delorie.com Fri Nov 10 02:39:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: cgf@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 02:39:00 -0000
Message-id: <200011101039.FAA29788@indy.delorie.com>
References: <20001109212032.A26464@redhat.com>
X-SW-Source: 2000-11/msg00062.html
Content-length: 392

> Date: Thu, 9 Nov 2000 21:20:32 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?

In my experience, there's nothing wrong with alloca as long as it is
used for allocating small buffers.  The only consideration is that not
every platform supports alloca.
From eliz@delorie.com Fri Nov 10 02:40:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: cgf@redhat.com
Cc: meissner@cygnus.com, gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 02:40:00 -0000
Message-id: <200011101040.FAA29793@indy.delorie.com>
References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> <20001109222231.A26675@redhat.com>
X-SW-Source: 2000-11/msg00063.html
Content-length: 979

> Date: Thu, 9 Nov 2000 22:22:31 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> You can, of course, have array overruns with an alloca'ed buffer just
> like you can with a malloced array.

IMHO, buffer overruns are irrelevant to this issue, since they happen
with automatic arrays as well, and are equally hard (or simple) to
track.

> Hmm.  I think that Purify actually does help track down stack corruption
> so there is at least one tool for this.  I've never used Electric Fence
> but I would be surprised if it was completely trivial to use and I would
> be equally surprised if linking with Electric Fence automatically
> pinpointed heap problems in every case.

You are right, as long as my experience goes.  Malloc debuggers are
anything but trivial to use, and some large programs which allocate
memory all the time, such as Emacs, are practically impossible to
debug using these tools, at least those of them which use page
protection to catch buffer overruns.
From jimb@zwingli.cygnus.com Fri Nov 10 06:21:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb@sources.redhat.com
Cc: Andrew Cagney <ac131313@cygnus.com>, Nick Duffek <nsd@redhat.com>
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 06:21:00 -0000
Message-id: <npem0j52m8.fsf@zwingli.cygnus.com>
References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com>
X-SW-Source: 2000-11/msg00064.html
Content-length: 263

I think alloca is terribly useful.  I have every intention of using it
the next time it's appropriate.  We should not reject new uses of
alloca.

Of course, strictly typed mechanisms, like GCC's dynamically sized
arrays, are preferable, but not widely available.
From cgf@redhat.com Fri Nov 10 08:16:00 2000
From: Chris Faylor <cgf@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 08:16:00 -0000
Message-id: <20001110111651.A19503@redhat.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com>
X-SW-Source: 2000-11/msg00065.html
Content-length: 581

On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>> Date: Thu, 9 Nov 2000 21:20:32 -0500
>> From: Christopher Faylor <cgf@redhat.com>
>> 
>> I was surprised by this assertion and so I thought I'd ask for a
>> consensus here.  Should the use of alloca be deprecated in gdb?
>
>In my experience, there's nothing wrong with alloca as long as it is
>used for allocating small buffers.  The only consideration is that not
>every platform supports alloca.

But, since alloca is already entrenched in gdb and available in liberty
I don't think this is an issue, is it?

cgf
From cgf@redhat.com Fri Nov 10 08:27:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 08:27:00 -0000
Message-id: <20001110112720.A19671@redhat.com>
References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com> <npem0j52m8.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-11/msg00066.html
Content-length: 501

On Fri, Nov 10, 2000 at 09:21:51AM -0500, Jim Blandy wrote:
>I think alloca is terribly useful.  I have every intention of using it
>the next time it's appropriate.  We should not reject new uses of
>alloca.
>
>Of course, strictly typed mechanisms, like GCC's dynamically sized
>arrays, are preferable, but not widely available.

I agree with this.  I use dynamically sized arrays in cygwin because it
is guaranteed to be compiled by gcc.

Are dynamically sized arrays part of C99 by any chance?

cgf
From fnasser@cygnus.com Fri Nov 10 08:42:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sources.redhat.com
Cc: Eli Zaretskii <eliz@is.elta.co.il>
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 08:42:00 -0000
Message-id: <3A0C2588.89C2B603@cygnus.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com>
X-SW-Source: 2000-11/msg00067.html
Content-length: 1229

Chris Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> From: Christopher Faylor <cgf@redhat.com>
> >>
> >> I was surprised by this assertion and so I thought I'd ask for a
> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?
> 

Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
our interpreter's command loops or the garbage collection becomes somewhat
random (it will only happen when you call alloca() for allocating some
other stuff and will only clean what was allocated by code that executed on frames
below the current stack position.

I think we have this bug when alloca() gets used right now.

(Nothing difficult, we just need to remember to do it)


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From cgf@redhat.com Fri Nov 10 08:46:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 08:46:00 -0000
Message-id: <20001110114629.A19882@redhat.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com>
X-SW-Source: 2000-11/msg00068.html
Content-length: 1331

On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
>Chris Faylor wrote:
>> 
>> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
>> >> From: Christopher Faylor <cgf@redhat.com>
>> >>
>> >> I was surprised by this assertion and so I thought I'd ask for a
>> >> consensus here.  Should the use of alloca be deprecated in gdb?
>> >
>> >In my experience, there's nothing wrong with alloca as long as it is
>> >used for allocating small buffers.  The only consideration is that not
>> >every platform supports alloca.
>> 
>> But, since alloca is already entrenched in gdb and available in liberty
>> I don't think this is an issue, is it?
>> 
>
>Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
>our interpreter's command loops or the garbage collection becomes somewhat
>random (it will only happen when you call alloca() for allocating some
>other stuff and will only clean what was allocated by code that executed on frames
>below the current stack position.
>
>I think we have this bug when alloca() gets used right now.
>
>(Nothing difficult, we just need to remember to do it)

% fgrep 'alloca (0)' *.c
gnu-regex.c:      alloca (0);
gnu-regex.c:  alloca (0);
gnu-regex.c:  alloca (0);
regcache.c:  alloca (0);
top.c:  alloca (0);

cgf
From bstell@ix.netcom.com Fri Nov 10 08:51:00 2000
From: bstell@ix.netcom.com
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: bstell@netscape.com, gdb@sources.redhat.com, Fernando Nasser <fnasser@cygnus.com>
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 08:51:00 -0000
Message-id: <3A0C2791.A33BE9AC@ix.netcom.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com>
X-SW-Source: 2000-11/msg00069.html
Content-length: 865

My goal is to reduce the "initial 
cognitive learning barrier" and
allow non experts to inspect data 
and help debug. 

Eli Zaretskii wrote:
> One way is to call the functions in the debuggee that convert these
> strings to a printable representation, then print the result ...
> Does that solve the problem?

If it can be put in a ".gdb_display_funcs"
and the user can type "p unichar_ptr"
and it works then that would be great.

Having to remember a display function puts
the knowledge burden on the (non expert) 
user. The user has to know the data type
and then know the display function.
Imagine the frustration if one had to type 
"p display_string(ptr)" every time they 
wanted to see a ascii string.

In just the same way I'm looking for
a way for the users not to have to
remember "p display_unichar(unichar_ptr)".

Doesn't gdb already know the data type?
From meissner@cygnus.com Fri Nov 10 09:05:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com, Eli Zaretskii <eliz@is.elta.co.il>
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 09:05:00 -0000
Message-id: <20001110120544.43205@cse.cygnus.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com>
X-SW-Source: 2000-11/msg00070.html
Content-length: 1721

On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
> Chris Faylor wrote:
> > 
> > On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> > >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> > >> From: Christopher Faylor <cgf@redhat.com>
> > >>
> > >> I was surprised by this assertion and so I thought I'd ask for a
> > >> consensus here.  Should the use of alloca be deprecated in gdb?
> > >
> > >In my experience, there's nothing wrong with alloca as long as it is
> > >used for allocating small buffers.  The only consideration is that not
> > >every platform supports alloca.
> > 
> > But, since alloca is already entrenched in gdb and available in liberty
> > I don't think this is an issue, is it?
> > 
> 
> Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
> our interpreter's command loops or the garbage collection becomes somewhat
> random (it will only happen when you call alloca() for allocating some
> other stuff and will only clean what was allocated by code that executed on frames
> below the current stack position.
> 
> I think we have this bug when alloca() gets used right now.
> 
> (Nothing difficult, we just need to remember to do it)

Note, that liberty's alloca will only be used if the host compiler is not GCC,
which probably makes it even harder to remember to use....  BTW, there are
systems out there that even's liberty's alloca will not work on (due to either
using a cactus stack or allocating the stack in pieces from the heap).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From fnasser@cygnus.com Fri Nov 10 09:08:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 09:08:00 -0000
Message-id: <3A0C2B9D.61C451F3@cygnus.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com> <20001110114629.A19882@redhat.com>
X-SW-Source: 2000-11/msg00071.html
Content-length: 1965

Christopher Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
> >Chris Faylor wrote:
> >>
> >> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> >> From: Christopher Faylor <cgf@redhat.com>
> >> >>
> >> >> I was surprised by this assertion and so I thought I'd ask for a
> >> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >> >
> >> >In my experience, there's nothing wrong with alloca as long as it is
> >> >used for allocating small buffers.  The only consideration is that not
> >> >every platform supports alloca.
> >>
> >> But, since alloca is already entrenched in gdb and available in liberty
> >> I don't think this is an issue, is it?
> >>
> >
> >Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
> >our interpreter's command loops or the garbage collection becomes somewhat
> >random (it will only happen when you call alloca() for allocating some
> >other stuff and will only clean what was allocated by code that executed on frames
> >below the current stack position.
> >
> >I think we have this bug when alloca() gets used right now.
> >
> >(Nothing difficult, we just need to remember to do it)
> 
> % fgrep 'alloca (0)' *.c
> gnu-regex.c:      alloca (0);
> gnu-regex.c:  alloca (0);
> gnu-regex.c:  alloca (0);
> regcache.c:  alloca (0);



> top.c:  alloca (0);

That takes care of the CLI commands.  (MI and Insight are probably broken)

Any other interpreter that uses the libgdb exported functions instead
of the CLI execute_command will have to do the same.  How can we control
that this is done if a script, for instance, calls random libgdb functions?

Maybe we will have to add a call to alloca(0) to every libgdb call.

(Or not used the darn thing!)

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fnasser@cygnus.com Fri Nov 10 09:13:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: bstell@ix.netcom.com
Cc: Eli Zaretskii <eliz@is.elta.co.il>, bstell@netscape.com, gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 09:13:00 -0000
Message-id: <3A0C2CB5.BF3CAB97@cygnus.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com>
X-SW-Source: 2000-11/msg00072.html
Content-length: 1183

Perhaps what you would like is a new output format specifiers to the
print and x commands? 

bstell@ix.netcom.com wrote:
> 
> My goal is to reduce the "initial
> cognitive learning barrier" and
> allow non experts to inspect data
> and help debug.
> 
> Eli Zaretskii wrote:
> > One way is to call the functions in the debuggee that convert these
> > strings to a printable representation, then print the result ...
> > Does that solve the problem?
> 
> If it can be put in a ".gdb_display_funcs"
> and the user can type "p unichar_ptr"
> and it works then that would be great.
> 
> Having to remember a display function puts
> the knowledge burden on the (non expert)
> user. The user has to know the data type
> and then know the display function.
> Imagine the frustration if one had to type
> "p display_string(ptr)" every time they
> wanted to see a ascii string.
> 
> In just the same way I'm looking for
> a way for the users not to have to
> remember "p display_unichar(unichar_ptr)".
> 
> Doesn't gdb already know the data type?

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From Eric.Mure@france.sun.com Fri Nov 10 11:03:00 2000
From: eric mure <Eric.Mure@france.sun.com>
To: gdb@sourceware.cygnus.com
Subject: relocated local static variables
Date: Fri, 10 Nov 2000 11:03:00 -0000
Message-id: <3A0C468A.E084918E@sunchorus.france.sun.com>
X-SW-Source: 2000-11/msg00073.html
Content-length: 2097

Hello,

We are porting GDB to debug MIPS relocatables.

We use -gdwarf-2, and most of debugging features works,
notably functions and global variables (.data and .bss)
can be accessed correctly after relocation (we use the
objfile_relocate function to relocate the symbols of
the executable file in memory after it has been loaded on
the target). But we have some problems with local static variables.

For example:

main()
{
    static int localStaticBss;
    ...
}

section .text is  relocated at 0xfa964000
section .bss  is  relocated at 0xfa963070

(gdb)info address localStaticBss
Symbol "localStaticBss"   is static storage at address 0xfa964000.

==> So gdb thinks that localStaticBss is in the .text section!

Dumping the Debug Attributes with dwarfdump:

<2><  155>      DW_TAG_variable
                DW_AT_name                  localStaticBss
                DW_AT_decl_file             1
                DW_AT_decl_line             19
                DW_AT_type                  <200>
                DW_AT_location              DW_OP_addr 0

Dumping the Symbol Table with nm:

[ 2] b 0x00 localStaticBss.3  section .bss

(gdb)info address localStaticBss.3
Symbol "localStaticBss.3" is static storage at address 0xfa963070.

So GDB does not see that these 2 symbols are in fact
the same variable.

First, I incorporated the following patch:
[PATCH RFA] dwarf2read.c: symbol relocation in new_symbol()
which relocate address of symbol by the base address
of the section it is in rather than always using
the base address of the .text section.
The function fixup_symbol_section call
lookup_minimal_symbol ("localStaticBss", ...)
But only "localStaticBss.3" is in the minimal
symbol table (name generated by the assembler).
So, the section field can't be updated.

The .symtab and .debug_info sections contains enough
informations to retrieve such value, but it doesn't
seem to be the right way to do.

Is there any patch or future implementation which deals with that ?

note: we use gcc version 2.8.1 and GNU gdb version 20001004
       -gstab is unsupported by this compiler.


Eric.
From ebachalo@redhat.com Fri Nov 10 11:07:00 2000
From: Eric Bachalo <ebachalo@redhat.com>
To: jtc@redback.com
Cc: Rudy Folden <rfolden@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: libremote activation
Date: Fri, 10 Nov 2000 11:07:00 -0000
Message-id: <3A0C4780.EA77ECE4@redhat.com>
References: <3A0B0F63.254C569A@redhat.com> <md5:100AB51E0F3A280FCC32E139FEAB08AE>
X-SW-Source: 2000-11/msg00074.html
Content-length: 2283

First, apologies for not getting libremote sources out to the public
yet.  We fully plan to release all libremote sources to the public in
the near future.  The only reason we haven't to date is a lack of
available resources to do it properly.

Libremote is our effort to make a standard framework under a single set
of sources for handling GDB remote protocol on the target side.  We plan
on releasing the code under a BSD like license.  This will eliminate
worries of linking this code with third party proprietary libraries.


Eric Bachalo
Director of Engineering
Red Hat, Inc.




"J.T. Conklin" wrote:
> 
> >>>>> "Rudy" == Rudy Folden <rfolden@redhat.com> writes:
> Rudy> Michael Snyder and I are working on what we believe to be the
> Rudy> first native version of libremote for an embedded Linux system.
> 
> Thanks for the explanation of what libremote is.  Note that I make the
> following suggestions knowing pretty much nothing about it.
> 
> * If GDB, or the remote protocol, needs to be changed in any way to
>   support automatic activation of libremote, there needs to be more
>   disclosure about what it is.  Even if it's kept redhat proprietary,
>   we'll need a spec so we can properly interface with it.
> 
> * Your comments about starting libremote via an inetd like mechanism
>   vs. starting it at runtime seem somewhat contradictory.  Yes, many
>   embedded systems have little memory, but the footprint of a debug
>   agent should be very small (10-20K).  If you have room to run an
>   inetd like program, you should be able to run a debug agent as well.
>   Note, if inetd is spawning the program, it's going to take the same
>   amount of memory as if it was spawned at system startup.
> 
> * Your comments about libremote stopping after GDB exits and needing
>   an instance for each program under debug are manifestations of
>   design bugs in the remote protocol.  A single debug agent should be
>   able to be started at system bringup; support debugging any number
>   of processes (and any number of threads); and should not exit when
>   GDB quits.  In order for the debug agent not to have to manage
>   multiple communication channels, that might be handled by a host-
>   side proxy.
> 
>         --jtc
> 
> --
> J.T. Conklin
> RedBack Networks
From fnasser@cygnus.com Fri Nov 10 11:44:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: jtc@redback.com
Cc: Rudy Folden <rfolden@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: libremote activation
Date: Fri, 10 Nov 2000 11:44:00 -0000
Message-id: <3A0C5019.F4539C79@cygnus.com>
References: <3A0B0F63.254C569A@redhat.com> <md5:3760B63B015868A532D1D3AD1F3599EF>
X-SW-Source: 2000-11/msg00075.html
Content-length: 1646

JT,

The libremote that Rudy was talking about is just some piece of software
to allow targets that do not speak the target protocol to be connected
to gdb.  It is a middleware, a translator, that talks the remote protocol
on one side and the alien protocol on the other. This way one don't have to
make gdb talk funky proprietary protocols or link it to non-GPLed libraries.
The remote protocol is all we need.

As Eric said in the previous message, it will soon be available as 
Open Source, as everything else that we do. At that time, people will
be able to start making suggestions, contributing with code and, most
importantly, using it.

It will come with some example directories and a few interfaces already in there
so that it will make it easier for people to understand how it works and how it
should be used.

We have tried it to connect to stand alone simulators, to a proprietary CORBA
interface to a Hardware Emulator and so on.  Michael Snyder stretched the concept
and reimplemented gdbserver using it (that was what Rudy was refering to).  
Someone else made it run inside an embedded device!  You can make virtually
anything speak the remote protocol now. 

As soon as the general public start playing with it we will see amazing things
being connected to GDB, all using the remote protocol.
Note that this being a library, we can eventually even have a new protocol and
these targets have just to be relinked to a new version of the libremote library.

We will have fun with it.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From eliz@delorie.com Fri Nov 10 12:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 12:00:00 -0000
Message-id: <200011101959.OAA00112@indy.delorie.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com>
X-SW-Source: 2000-11/msg00076.html
Content-length: 421

> Date: Fri, 10 Nov 2000 11:16:51 -0500
> From: Chris Faylor <cgf@redhat.com>
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?

I don't think this should be an issue.
From eliz@delorie.com Fri Nov 10 12:09:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: bstell@ix.netcom.com
Cc: bstell@netscape.com, gdb@sources.redhat.com, fnasser@cygnus.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 12:09:00 -0000
Message-id: <200011102009.PAA00126@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com>
X-SW-Source: 2000-11/msg00077.html
Content-length: 1369

> From: bstell@ix.netcom.com
> Date: Fri, 10 Nov 2000 08:51:29 -0800
> 
> Eli Zaretskii wrote:
> > One way is to call the functions in the debuggee that convert these
> > strings to a printable representation, then print the result ...
> > Does that solve the problem?
> 
> If it can be put in a ".gdb_display_funcs"
> and the user can type "p unichar_ptr"
> and it works then that would be great.

That would require GDB to support every possible charset out there;
Unicode is not the only game in town.

While it would be extremely nice if GDB knew about all the charsets
and their encodings, it looks like a terribly huge job to add that.

> Having to remember a display function puts
> the knowledge burden on the (non expert) 
> user. The user has to know the data type
> and then know the display function.

I'm assuming that a person who debugs a program knows something about
its internals, including how it represents non-ASCII characters.

> Imagine the frustration if one had to type 
> "p display_string(ptr)" every time they 
> wanted to see a ascii string.

That's exactly what I need to do when, for example, I need to print a
Lisp data structure, such as an alist, when I debug Emacs.

> Doesn't gdb already know the data type?

GDB knows the data type, but it doesn't necessarily know how to
generate a human-readable representation of that data type.
From eliz@delorie.com Fri Nov 10 12:10:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: fnasser@cygnus.com
Cc: bstell@ix.netcom.com, bstell@netscape.com, gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 12:10:00 -0000
Message-id: <200011102010.PAA00131@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <3A0C2CB5.BF3CAB97@cygnus.com>
X-SW-Source: 2000-11/msg00078.html
Content-length: 331

> Date: Fri, 10 Nov 2000 12:13:25 -0500
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> Perhaps what you would like is a new output format specifiers to the
> print and x commands? 

That would be the desired solution, I guess.  But it requires GDB to
know about UTF-8, UTF-16, and all the other possible encoding like
ISO-2022.
From bstell@netscape.com Fri Nov 10 16:08:00 2000
From: bstell@netscape.com (Brian Stell)
To: gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 16:08:00 -0000
Message-id: <3A0C8E19.A8A6D355@netscape.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com>
X-SW-Source: 2000-11/msg00079.html
Content-length: 681

We all agree that gdb by itself cannot display every data
type that will come along.

What I'm looking for is a way for an expert user to tell
gdb how to display a given type. This way within a
community of developers the expert users can setup
display routines for the complex data types in that
environment and everyone else can view the data
in gdb.

For example, in the Mozilla development world there are a
large number of developers and a variety of string formats
(PRUnichar=UTF16, nsString=C++ object, etc.) and more
are expected in the future (e.g.: a compressed format).

It is easy to say RTFM but it would be more effective
to say "copy this file to your home dir".