Mike Frysinger | 1 May 02:10 2008
Picon

Re: the "load" command and the .bss section

On Monday 28 April 2008, Michael Snyder wrote:
> On Sun, 2008-04-27 at 05:09 -0400, Mike Frysinger wrote:
> > i was doing a new board port using jtag and so was leveraging the "load"
> > command to setup the initial ELF in the relevant memory regions.  things
> > kept crashing on me and then i realized that the loading process wasnt
> > actually zeroing out the bss.  is there a reason for this ?  i googled
> > and flipped through the manual, but the details on what exactly the
> > "load" command is supposed to do is a bit on sketchy side.  from what i
> > can tell from the gdb source code and the actual output from running the
> > command, it walks the section headers (rather than the program headers ?)
> > and loads up everything that is in the file.  since the bss section
> > doesnt actually exist in the file and is only allocated, that is why it
> > gets skipped ?
> >
> > once i adapted my habits to first load the ELF and then manually zero the
> > bss, life was so much saner :).
>
> In my understanding, it is not GDB's responsibility to zero the
> .bss section.  That is the responsibility of the C Runtime.
>
> Otherwise, how could the program run without gdb in the picture?
>
> The gdb load command only addresses sections with the loadable
> flag.  .bss is not loadable.

a fair point, but i think there is a valid use case for having an optional 
flag to tell gdb to do this.  you may want to load a bare metal application 
that itself would have normally been loaded by another application (say your 
typical bootloader), so the assumption is that certain aspects of the C 
runtime have been initialized before the bare metal application is executed.  
(Continue reading)

Michael Snyder | 1 May 04:03 2008

Re: the "load" command and the .bss section

On Wed, 2008-04-30 at 20:10 -0400, Mike Frysinger wrote:
> On Monday 28 April 2008, Michael Snyder wrote:
> > On Sun, 2008-04-27 at 05:09 -0400, Mike Frysinger wrote:
> > > i was doing a new board port using jtag and so was leveraging the "load"
> > > command to setup the initial ELF in the relevant memory regions.  things
> > > kept crashing on me and then i realized that the loading process wasnt
> > > actually zeroing out the bss.  is there a reason for this ?  i googled
> > > and flipped through the manual, but the details on what exactly the
> > > "load" command is supposed to do is a bit on sketchy side.  from what i
> > > can tell from the gdb source code and the actual output from running the
> > > command, it walks the section headers (rather than the program headers ?)
> > > and loads up everything that is in the file.  since the bss section
> > > doesnt actually exist in the file and is only allocated, that is why it
> > > gets skipped ?
> > >
> > > once i adapted my habits to first load the ELF and then manually zero the
> > > bss, life was so much saner :).
> >
> > In my understanding, it is not GDB's responsibility to zero the
> > .bss section.  That is the responsibility of the C Runtime.
> >
> > Otherwise, how could the program run without gdb in the picture?
> >
> > The gdb load command only addresses sections with the loadable
> > flag.  .bss is not loadable.
> 
> a fair point, but i think there is a valid use case for having an optional 
> flag to tell gdb to do this.  you may want to load a bare metal application 
> that itself would have normally been loaded by another application (say your 
> typical bootloader), so the assumption is that certain aspects of the C 
(Continue reading)

Daniel Jacobowitz | 1 May 05:32 2008

Re: the "load" command and the .bss section

On Wed, Apr 30, 2008 at 07:03:00PM -0700, Michael Snyder wrote:
> That's why there are different implementations of "load".
> A bare-metal target would presumably wind up using the 
> appropriate "load" version.

Well that's probably why historically there _were_ different
implementations of load.  But I doubt it is still justified.

Only the three m32r targets, the remote-mips target (for specific
monitors), remote-sim, and target remote have implementations of load.
It looks to me like target remote's would work for all of them except
the sim.  m32r is just using a wrapper around generic_load already.
monitor and mips are using srec but could do that anyway for large
writes.  Presumably, at least.  But I have no way to test any of them
so I leave them alone.

--

-- 
Daniel Jacobowitz
CodeSourcery

Vladimir Prus | 1 May 18:15 2008

Re: MI non-stop interface details

On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
> Pedro Alves wrote:
> > I can't see how is it different -- in the frontend's perspective --
> > of keeping track of what to pass to --thread= *provided GDB doesn't switch 
> > threads automatically*.  But then again, I'm no frontend writer.
> >   
> 
> Using -thread-select makes it easier for the front end to be compatible 
> with older versions of GDB.

Hmm, I though that only reason that -thread-select is simpler is because
in DSF, specifically, there's no central place where commands are send
and where --thread can be conveniently added. I'm not saying this is good,
or bad, but this is not the case for all frontend. Am I wrong?

- Volodya

Pawel Piech | 1 May 18:30 2008

Re: MI non-stop interface details

Vladimir Prus wrote:
> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>   
>> Pedro Alves wrote:
>>     
>>> I can't see how is it different -- in the frontend's perspective --
>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch 
>>> threads automatically*.  But then again, I'm no frontend writer.
>>>   
>>>       
>> Using -thread-select makes it easier for the front end to be compatible 
>> with older versions of GDB.
>>     
>
> Hmm, I though that only reason that -thread-select is simpler is because
> in DSF, specifically, there's no central place where commands are send
> and where --thread can be conveniently added. I'm not saying this is good,
> or bad, but this is not the case for all frontend. Am I wrong?
>
> - Volodya
>   
In DSF-GDB there _is_ a central place where commands are sent, this is 
where the protocol state is adjusted using -thread-select.  However, the 
--thread option is being added to many but not all commands, so the same 
mechanism that adds the -thread-select could not be reused to add 
--thread option.  Instead each command which accepts --thread that would 
need to be adjusted to use the --thread, but only when in non-stop 
debugging mode.

-Pawel
(Continue reading)

Vladimir Prus | 1 May 18:37 2008

Re: MI non-stop interface details

Pawel Piech wrote:

> Vladimir Prus wrote:
>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>   
>>> Pedro Alves wrote:
>>>     
>>>> I can't see how is it different -- in the frontend's perspective --
>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>> threads automatically*.  But then again, I'm no frontend writer.
>>>>   
>>>>       
>>> Using -thread-select makes it easier for the front end to be compatible
>>> with older versions of GDB.
>>>     
>>
>> Hmm, I though that only reason that -thread-select is simpler is because
>> in DSF, specifically, there's no central place where commands are send
>> and where --thread can be conveniently added. I'm not saying this is good,
>> or bad, but this is not the case for all frontend. Am I wrong?
>>
>> - Volodya
>>   
> In DSF-GDB there _is_ a central place where commands are sent, this is
> where the protocol state is adjusted using -thread-select.  However, the
> --thread option is being added to many but not all commands, so the same
> mechanism that adds the -thread-select could not be reused to add
> --thread option.  Instead each command which accepts --thread that would
> need to be adjusted to use the --thread, but only when in non-stop
> debugging mode.
(Continue reading)

Pawel Piech | 1 May 18:56 2008

Re: MI non-stop interface details

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> Vladimir Prus wrote:
>>     
>>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>>   
>>>       
>>>> Pedro Alves wrote:
>>>>     
>>>>         
>>>>> I can't see how is it different -- in the frontend's perspective --
>>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>>> threads automatically*.  But then again, I'm no frontend writer.
>>>>>   
>>>>>       
>>>>>           
>>>> Using -thread-select makes it easier for the front end to be compatible
>>>> with older versions of GDB.
>>>>     
>>>>         
>>> Hmm, I though that only reason that -thread-select is simpler is because
>>> in DSF, specifically, there's no central place where commands are send
>>> and where --thread can be conveniently added. I'm not saying this is good,
>>> or bad, but this is not the case for all frontend. Am I wrong?
>>>
>>> - Volodya
>>>   
>>>       
(Continue reading)

Vladimir Prus | 1 May 18:59 2008

Re: MI non-stop interface details

On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:

> > In DSF-GDB there _is_ a central place where commands are sent, this is
> > where the protocol state is adjusted using -thread-select.  However, the
> > --thread option is being added to many but not all commands, so the same
> > mechanism that adds the -thread-select could not be reused to add
> > --thread option.  Instead each command which accepts --thread that would
> > need to be adjusted to use the --thread, but only when in non-stop
> > debugging mode.
>     
> 
> This is not actually. The plan is for eery command will accept --thread.  
> Those that don't have any use of it will ignore it. The only command,
> at the moment, for which the meaning of --thread is not yet clear, and for
> which the frontend might have to have custom decision logic, is --exec-continue.
> 
> - Volodya
>   
>  That's helpful.  Unfortunately UI clients that want to have a wide user base still 
>  need to worry about old GDB versions which do not support -thread, and that was my 
>  first point in this thread.  As I've seen on this mailing list there are users out 
>  there still on GDB 5.x.  I expect it will take several 
>  years before support for GDB 6.8 and prior is not so important.    

And where's the issue? On startup, issue -list-features. If you get error, this is old
GDB. If the output of -list-features does not include "thread-option", this version of
GDB does not support --thread (and don't not support non-stop, either). Then, you
can make appropriate runtime decisions. It seems better to me to make such global
decision right after starting GDB, rather than guessing things from output of *stopped,
and other indirect mechanisms.
(Continue reading)

Vladimir Prus | 1 May 19:11 2008

Re: MI non-stop interface details

On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
> Vladimir Prus wrote:
> > Again -- exec-continue resuming just one thread will be a change in behaviour.
> > We can take two approaches:
> >
> > 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
> > be used both in all-stop and non-stop mode). We're in position to change anything
> > we like, and are not bound by backward compatibility, or anything.
> >
> > 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
> > Pawel's opposition to the --thread idea indicates that he prefers this approach.
> > Then, we rather not change the behaviour of existing commands.
> >
> > There are not many high-level warts in MI2/non-stop/async, so I'm willing
> > to go with (2).
> >
> > - Volodya
> >   
> 
> First of all I really appreciate your effort to maintain backward 
> compatibility.  I know that it can seriously complicate the effort to 
> add new features but I believe this effort pays off in quicker and more 
> reliable adoption by the users (IDEs).  However, there are two kinds of 
> backward compatibility goals to consider:
> 1) Allowing old GDB clients to use the new, extended protocol.
> 2) Allow clients that use the extended protocol to easily work with old 
> protocol versions.  And by "easily", I mean that the client should be 
> able to not have "if(non-stop) { use command a } else { use command b}" 
> kind of logic scattered throughout its implementation.

(Continue reading)

Vladimir Prus | 1 May 19:21 2008

Re: MI non-stop interface details

On Wednesday 30 April 2008 18:34:48 Pedro Alves wrote:
> A Wednesday 30 April 2008 07:59:43, Vladimir Prus wrote:
> > On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote:
> > > A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote:
> > > > > Pedro Alves wrote:
> > > > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > > > making the case of not passing a --thread parameter semantics
> > > > > match?  Given the same arguments, if one resumes just one thread,
> > > > > the others should too, IMHO.
> > > >
> > > > Too late. -exec-continue resumes everything. -exec-step, from user
> > > > standpoint, resumes one -- most users don't even know that step
> > > > can resume all threads.
> > >
> > > Oh, I'm talking non-stop mode.  It's not too late for that.
> > >
> > > I played a bit with eclipse/java debugging (which implements non-stop),
> > > and noticed it only resumes one thread when one clicks the
> > > equivalent of "continue".  I have used eclipse/java heavilly in the
> > > past, and I never found that unintuitive.  I remember
> > > looking for a "continue all" button and not finding one, but normally
> > > I didn't even thing about it.  Resuming one thread was just fine.
> >
> > Opinions differ. I think Eclipse behaviour optimized for non-common
> > cases. Maybe this non-stop behaviour is good for that J2EE kind of thing,
> > with zillion of threads, but it's not a good default behaviour for
> > debugging ordinary applications.
> >
> 
> Eh, indeed my experience is mostly with debugging live J2EE systems.
(Continue reading)


Gmane