headers
Daniel Berlin | 1 May 2003 04:13

Re: breakpoints in constructors


On Wednesday, April 30, 2003, at 10:43  AM, Michael Elizabeth Chastain 
wrote:

> Hi Daniel,
>
>> It's not required multi-object-code, it's only required that it does
>> the right thing when called with a certain name  (not the same at all,
>> since one can  just make up the symbols for the constructors that 
>> start
>> at the right points in the "one object code constructor" function,
>> without even having to make stub functions with gotos in them. Just
>> multiple symbol names and one object code).
>
> I see what you mean.  The ABI requirements are that there be two or 
> three
> labels, and that the labels have different semantics.  It was just an
> assumption on my part that C++ compilers always emit distinct,
> single-entry-point functions.

It was just a "it's simple to implement this way, we'll optimize it 
later" thing, i think.
You know, of the "why not keep the ABI implementation simple before we 
make it buggy" thought? :P
>
>> One way is to make one "visible" breakpoint and 2 "hidden" 
>> breakpoints.
>> This is a bit ugly, unless you special case the breakpoint printouts 
>> so
>> that it says the one "visible" breakpoint is at pc x, y, z, rather
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Cagney | 1 May 2003 20:40
Picon
Favicon

Inferior function call command set

Hello,

GDB has a number of commands for controlling the behavior of inferior 
function calls (developers think of them as call dummies).  Looking in 
"infcall.c" I find:

	set/show coerce-float-to-double yes|no
	set/show unwindonsignal yes|no

And I'm now looking to add a third:

	set/show call-location on-stack|at-start|auto

So:

- anyone got a better name for this new command?

- should these be re-grouped into a set of sub commands vis:

	set/show call coerce-float-to-double yes|no
	set/show call unwind-on-signal yes|no
	set/show call breakpoint-location on-stack|at-entry|auto

I'm figuring that "(gdb) set call" should provide a rough correspondance 
to the existing "(gdb) call" command.

Comment away ...

Andrew
(Continue reading)

Permalink | Reply | 5 comments |
headers
Doug Evans | 1 May 2003 23:12

Inferior function call command set

Andrew Cagney writes:
 > GDB has a number of commands for controlling the behavior of inferior 
 > function calls (developers think of them as call dummies).  Looking in 
 > "infcall.c" I find:
 > 
 > 	set/show coerce-float-to-double yes|no
 > 	set/show unwindonsignal yes|no
 > 
 > And I'm now looking to add a third:
 > 
 > 	set/show call-location on-stack|at-start|auto

Questions:

Out of curiousity, is there any need to have a runtime choice?

What happens if a value is set that the target doesn't support?
I presume this will be flagged as an error, right?

Is there any target that actually supports more than one?
(and that has all forms consistently working, rather than the
usual one working and the others bitrotting away ...)
Permalink | Reply | 4 comments |
headers
Andrew Cagney | 1 May 2003 23:28
Picon
Favicon

Re: Inferior function call command set

> Andrew Cagney writes:
>  > GDB has a number of commands for controlling the behavior of inferior 
>  > function calls (developers think of them as call dummies).  Looking in 
>  > "infcall.c" I find:
>  > 
>  > 	set/show coerce-float-to-double yes|no
>  > 	set/show unwindonsignal yes|no
>  > 
>  > And I'm now looking to add a third:
>  > 
>  > 	set/show call-location on-stack|at-start|auto
> 
> Questions:
> 
> Out of curiousity, is there any need to have a runtime choice?

Entry point in ROM, non 1:1 code/stack, ...

> What happens if a value is set that the target doesn't support?
> I presume this will be flagged as an error, right?
> 
> Is there any target that actually supports more than one?
> (and that has all forms consistently working, rather than the
> usual one working and the others bitrotting away ...)

An addition to the testsuite is implicit.

Andrew
(Continue reading)

Permalink | Reply | 3 comments |
headers
Doug Evans | 1 May 2003 23:49

Re: Inferior function call command set

Andrew Cagney writes:
 > > Out of curiousity, is there any need to have a runtime choice?
 > 
 > Entry point in ROM, non 1:1 code/stack, ...

Apologies, still confused.
[having spent the last few days buried in the guts of
hand-called-function support such things are very much on my
mind these days]

How does having an entry point in ROM affect things?
It appears to me that all AT_ENTRY_POINT does is use the entry point
address as a magic number that will "never appear" in user code.
[thus if the callee is returning to it you know you're back in the "stub"]

In my port I added the ability for the user to override
CALL_DUMMY_ADDRESS since the entry point is ambiguous/unspecified.
[THAT would be a very welcome addition to the mainline code. :-)]
Pproviding both AT_ENTRY_POINT and ON_STACK is _far_ more effort than
providing the ability to override what gdb uses for CALL_DUMMY_ADDRESS.
Perhaps what I should have done is just hardwire it to 42.  1/2 :-).

No claim is made that there isn't a need for the runtime
stack/entry-point choice.  But I still don't understand the need for it.
[Not that anyone has to spend time clearing up my understanding of course;
but if it's not that much effort, or if other people are also curious ...]

 > An addition to the testsuite is implicit.

Ah.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Cagney | 2 May 2003 00:48
Picon
Favicon

Re: Inferior function call command set

> Andrew Cagney writes:
>  > > Out of curiousity, is there any need to have a runtime choice?
>  > 
>  > Entry point in ROM, non 1:1 code/stack, ...
> 
> Apologies, still confused.
> [having spent the last few days buried in the guts of
> hand-called-function support such things are very much on my
> mind these days]
> 
> How does having an entry point in ROM affect things?
> It appears to me that all AT_ENTRY_POINT does is use the entry point
> address as a magic number that will "never appear" in user code.
> [thus if the callee is returning to it you know you're back in the "stub"]

GDB tries to insert a breakpoint at that address (that doesn't work when 
it is in a ROM :-) Looking at the MIPS, it turned out to also not work 
very well when the entry point couldn't be found.

> In my port I added the ability for the user to override
> CALL_DUMMY_ADDRESS since the entry point is ambiguous/unspecified.
> [THAT would be a very welcome addition to the mainline code. :-)]
> Pproviding both AT_ENTRY_POINT and ON_STACK is _far_ more effort than
> providing the ability to override what gdb uses for CALL_DUMMY_ADDRESS.
> Perhaps what I should have done is just hardwire it to 42.  1/2 :-).

That isn't true.

For an up-to-date architecture, assuming the stack is executable(1), 
there should be zero change.  In fact, given problems with finding the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Evans | 2 May 2003 00:59

Re: Inferior function call command set

Andrew Cagney writes:
 > GDB tries to insert a breakpoint at that address

Ah, yes.  Forgot about that part.  Thanks.

[In my target having a (pseudo-)arbitrary call-dummy-address
isn't a problem, so I kinda glossed over that part in my mind.  Oh well.]
Permalink | Reply | 0 comments |
headers
Andrew Cagney | 2 May 2003 01:09
Picon
Favicon

Re: [rfc] struct dictionary

Jim,

Is it ok to remove BLOCK_SHOULD_SORT how?

Andrew
Permalink | Reply | 3 comments |
headers
Jim Blandy | 2 May 2003 01:18
Picon
Favicon

Re: I have returned to the land of free software


Michael Meissner <gdb-mail <at> the-meissners.org> writes:
> After some periods of unemployment and working for a non-free
> software company, I find myself beginning a binutils/GCC/GDB port
> once again.

Long time no see!  :)

I'll send you the forms off-list.
Permalink | Reply | 0 comments |
headers
Jim Blandy | 2 May 2003 01:29
Picon
Favicon

Re: DWARF problem - newbie question


"Lev Assinovsky" <LAssinovsky <at> algorithm.aelita.com> writes:

> Hi!
> I use gcc 3.2 and gdb+dejagnu-20030228.
> Compile my code with -ggdb option which promises 
> the most expressive extra debug info.
> But when in gdb I request "info macro M"
> I get:
> GDB has no preprocessor macro information for that code, though
> I do have macro M defined in my source.
> 
> What am I doing wrong?

At the moment, to get macro information, you need to:
- use the Dwarf 2 debugging format, and
- pass GCC the -g3 flag, to ask it to include macro information.

You don't say which platform you're using.  On i686-pc-linux-gnu, GCC
3.2 defaults to using Dwarf 2.  You can check for sure by running
'readelf -S foo.o' on one of your .o files, compiled with plain -g:
- If it has a section named '.debug_info', then that's Dwarf 2.
- If it has a section named '.stab', then that's STABS.

If Dwarf 2 isn't the default, then you can request it with -gdwarf-2.
So altogether, you'd need to say '-gdwarf-2 -g3'.

I don't really know how -ggdb decides which format is 'the most
expressive'.  I think it's better to spell out what you want than to
use that flag.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane