headers
Robert Dewar | 1 Feb 2007 02:12
Favicon

Re: GDB Stub & GPL question

Nicholas Mc Guire wrote:

>                  THIS SOFTWARE IS NOT COPYRIGHTED
> 
> how does that fit with there being a GPL problem ? - if there really is
> then these headers sould be changed as the expectation is clearly 
> different.

Such a header has no legal significance, so if you want to copy
this code, it is up to you to check that the author has indeed
issued an appropriate license, and/or disclaimed copyright (I
think this is possible in the US, it is not possible in many
European countries as I understand things).

Also, any answer you get to a legal question about licensing
on this forum has no legal significance (and that includes
this answer).
Permalink | Reply | 2 comments |
headers
Nicholas Mc Guire | 1 Feb 2007 05:33
Picon

Re: GDB Stub & GPL question


> Nicholas Mc Guire wrote:
>
>>                  THIS SOFTWARE IS NOT COPYRIGHTED
>> 
>> how does that fit with there being a GPL problem ? - if there really is
>> then these headers sould be changed as the expectation is clearly 
>> different.
>
> Such a header has no legal significance, so if you want to copy
> this code, it is up to you to check that the author has indeed
> issued an appropriate license, and/or disclaimed copyright (I
> think this is possible in the US, it is not possible in many
> European countries as I understand things).
>
> Also, any answer you get to a legal question about licensing
> on this forum has no legal significance (and that includes
> this answer).
>
well I did not post an answer I posted a qutestion of "how does
that fit with a GPL problem" - that this list does not need an explicid
INAL in every mail is clear to everybody I hope ;)

Never the less it would make sense to change these boilerplates if they
do not provide any legally relevant information as they do lead to 
confusion when read by some people (me atleast).

hofrat
Permalink | Reply | 1 comment |
headers
Robert Dewar | 1 Feb 2007 10:44
Favicon

Re: GDB Stub & GPL question

Nicholas Mc Guire wrote:

> Never the less it would make sense to change these boilerplates if they
> do not provide any legally relevant information as they do lead to 
> confusion when read by some people (me atleast).

Absolutely, it is appropriate that headers be right. Even if copyright
notices are no longer a legal requirement, they should be present and
correct (and the copyright office thinks they may be relevant in an
"innocent infringement" defense which might mitigate damages, see

http://www.copyright.gov/circs/circ03.html
Permalink | Reply | 0 comments |
headers
Bahadir Balban | 1 Feb 2007 11:48
Picon

breakpoint on non-function symbol

Hi,

Is it possible to put a breakpoint on a symbol that is not a function?

I have two elf images, the first is a loader that contains the second
image in itself. I want to refer to a symbol defined in the second
from the first. To achieve that, I extracted the symbol from second
and defined it as a variable in the linker script of the first. When I
break on  the symbol gdb complains its not a function. I could
possibly define it as a function in assembler but I've done enough
tweaks; don't want to add more unless you have a better suggestion.

Thanks,
Bahadir
Permalink | Reply | 4 comments |
headers
Andreas Schwab | 1 Feb 2007 12:01
Picon

Re: breakpoint on non-function symbol

"Bahadir Balban" <bahadir.balban <at> gmail.com> writes:

> Is it possible to put a breakpoint on a symbol that is not a function?

You can put a breakpoint at any address with the "break *ADDR" syntax.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 3 comments |
headers
Bahadir Balban | 1 Feb 2007 12:26
Picon

Re: breakpoint on non-function symbol

On 2/1/07, Andreas Schwab <schwab <at> suse.de> wrote:
> "Bahadir Balban" <bahadir.balban <at> gmail.com> writes:
>
> > Is it possible to put a breakpoint on a symbol that is not a function?
>
> You can put a breakpoint at any address with the "break *ADDR" syntax.
>
> Andreas.

The problem is the address is not known in advance, so I had to rely
on the symbol. Anyway, I fixed it in assembler by:

.global symname;
.type symname, function;
.equ symname, addr

rather than including it in the linker script.

Thanks,
Bahadir
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Feb 2007 13:20

Re: breakpoint on non-function symbol

On Thu, Feb 01, 2007 at 11:26:34AM +0000, Bahadir Balban wrote:
> The problem is the address is not known in advance, so I had to rely
> on the symbol. Anyway, I fixed it in assembler by:
> 
> .global symname;
> .type symname, function;
> .equ symname, addr
> 
> rather than including it in the linker script.

That works, or you can take advantage of what Andreas suggested:

set $var = &symbol
break *$var

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Feb 2007 18:53
Favicon

Re: How to tell gdb about dlls using remote protocol

Hi Daniel,

> > The problem that I have run into, is that I can find no way to let gdb know 
> > what dll's are inside the
> > debugee using the remote protocol.
> > 
> > Does anyone know if there is a way to do this ?
> 
> There's no way to do this yet.  If you look at the list archives for
> the last several months, you'll see a patch (in the "GDB solib
> interface" thread) that implements something which might help.  But it
> hasn't been finalized or committed yet (sorry Stephen - I just haven't
> had time).

This makes me wonder how well the debugger can work in certain
situations like when backtracing from DLL code. If the debugger
doesn't know where it is, then it's probably let to prologue analysis
to do the unwinding. Except that it cannot determine where the prologue
is... In that case, I see that the i386 unwinder assumes that the frame
base can be deduced from the SP and the SP offset. Unfortunately,
this SP offset can only be deduced from prologue analysis. Catch 22?

Mark,

What do you think of this (untested) patch? We we couldn't find
the function start address, the safest seems to be relying on ebp.

--

-- 
Joel
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mark Kettenis | 1 Feb 2007 23:51
Picon
Picon
Favicon

Re: GDB Stub & GPL question

> Date: Wed, 31 Jan 2007 10:04:48 -0500
> From: Daniel Jacobowitz <drow <at> false.org>
>
> > Another question is regarding GPL...  some part of stub code will
> > be residing in our kernel which is proprietary.  Does that mean we
> > will have to release the code for kernel as well ?
> 
> If you copy the stub from the GDB source tree, then yes you would
> have a GPL problem.  I recommend writing one from scratch, instead,
> based on the documentation - that's what most people seem to do.
> The examples in GDB are quite old.

I actually recommend releasing all your code under the GPL.

(sorry couldn't resist)

Mark
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Feb 2007 23:54

Re: How to tell gdb about dlls using remote protocol

On Thu, Feb 01, 2007 at 09:53:11AM -0800, Joel Brobecker wrote:
> This makes me wonder how well the debugger can work in certain
> situations like when backtracing from DLL code. If the debugger
> doesn't know where it is, then it's probably let to prologue analysis
> to do the unwinding. Except that it cannot determine where the prologue
> is... In that case, I see that the i386 unwinder assumes that the frame
> base can be deduced from the SP and the SP offset. Unfortunately,
> this SP offset can only be deduced from prologue analysis. Catch 22?

In general, if we can not find the start of the current function,
we have absolutely no chance of getting out of it.

This is a standard problem e.g. with the Windows system DLLs, since
we have inadequate means to recover symbol information from them.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 10 comments |

Gmane