* GDB 5.2 vs. Ada (and probably other unknown languages)
@ 2002-03-31 2:46 Florian Weimer
2002-04-03 8:47 ` Andrew Cagney
2002-04-11 14:17 ` Michael Snyder
0 siblings, 2 replies; 7+ messages in thread
From: Florian Weimer @ 2002-03-31 2:46 UTC (permalink / raw)
To: gdb
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
It seems that GDB (starting with 5.1.1 or so) can no longer debug
programs written in languages unknown to it. With previous GDB
versions, you could at least set breakpoints, get backtraces, and
examine most variables, although you had to take name mangling into
account.
For example, if I try to set a breakpoint in an Ada program, I just
get the error message "internal error - unimplemented function
unk_lang_create_fundamental_type called."
Is there a workaround? Even if full Ada support is not available,
getting backtraces would be helpful in some cases.
Here's a small, stand-alone test program (you have to compile it using
"gcc -S -g no_debug.adb && gcc no_debug.s", as it doesn't use the Ada
run-time library).
package No_Debug is
procedure Main;
pragma Export (C, Main, "main");
end No_Debug;
with System; use System;
package body No_Debug is
procedure Puts (Str : Address);
pragma Import (C, Puts, "puts");
Message : constant String := "Hello, world!" & ASCII.NUL;
procedure Main is
begin
Puts (Message'Address);
end Main;
end No_Debug;
I've attached the x86 assembler code below, in case you want to
experiment yourself without having to install Ada.
[-- Attachment #2: no_debug.s --]
[-- Type: text/plain, Size: 10577 bytes --]
.file "no_debug.adb"
.file 1 "no_debug.adb"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.file 2 "/opt/gcc3/lib/gcc-lib/i686-pc-linux-gnu/3.2/adainclude/system.ads"
.comm no_debug_E,1,1
.data
.type no_debug__message,@object
.size no_debug__message,14
no_debug__message:
.string "Hello, world!"
.text
.align 2
.globl main
.type main,@function
main:
.LFB1:
.loc 1 10 0
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
.loc 1 12 0
movl $no_debug__message, (%esp)
call puts
leave
ret
.LFE1:
.Lfe1:
.size main,.Lfe1-main
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0
.LSCIE0:
.long 0xffffffff
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0
.LASFDE0:
.long .Lframe0
.long .LFB1
.long .LFE1-.LFB1
.byte 0x4
.long .LCFI0-.LFB1
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE0:
.text
.Letext0:
.section .debug_info
.long 0x2b6
.value 0x2
.long .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.long .Ldebug_line0
.long .Letext0
.long .Ltext0
.long .LC42
.long .LC43
.long .LC44
.byte 0x3
.uleb128 0x2
.long 0x3e
.long .LC2
.byte 0x10
.byte 0x1
.byte 0x3
.uleb128 0x3
.string "F"
.byte 0x1
.byte 0x3
.long 0x3e
.byte 0x2
.byte 0x23
.uleb128 0x0
.byte 0x0
.uleb128 0x4
.long .LC10
.byte 0xc
.byte 0x4
.uleb128 0x5
.long 0x5e
.long .LC45
.byte 0x1
.byte 0x2
.byte 0x1
.uleb128 0x6
.long .LC0
.byte 0x0
.uleb128 0x6
.long .LC1
.byte 0x1
.byte 0x0
.uleb128 0x2
.long 0xbf
.long .LC3
.byte 0x14
.byte 0x2
.byte 0x1
.uleb128 0x7
.long .LC4
.byte 0x2
.byte 0x1
.long 0x45
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x7
.long .LC5
.byte 0x2
.byte 0x1
.long 0xbf
.byte 0x2
.byte 0x23
.uleb128 0x1
.uleb128 0x7
.long .LC6
.byte 0x2
.byte 0x1
.long 0xc6
.byte 0x2
.byte 0x23
.uleb128 0x4
.uleb128 0x7
.long .LC7
.byte 0x2
.byte 0x1
.long 0xcd
.byte 0x2
.byte 0x23
.uleb128 0x8
.uleb128 0x7
.long .LC8
.byte 0x2
.byte 0x1
.long 0xcd
.byte 0x2
.byte 0x23
.uleb128 0xc
.uleb128 0x7
.long .LC9
.byte 0x2
.byte 0x1
.long 0xd3
.byte 0x2
.byte 0x23
.uleb128 0x10
.byte 0x0
.uleb128 0x4
.long .LC11
.byte 0x1
.byte 0x7
.uleb128 0x4
.long .LC12
.byte 0x4
.byte 0x7
.uleb128 0x8
.byte 0x4
.long 0xbf
.uleb128 0x4
.long .LC13
.byte 0x4
.byte 0x5
.uleb128 0x2
.long 0x103
.long .LC14
.byte 0x8
.byte 0x1
.byte 0x8
.uleb128 0x3
.string "LB0"
.byte 0x1
.byte 0x8
.long 0x103
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x3
.string "UB0"
.byte 0x1
.byte 0x8
.long 0x103
.byte 0x2
.byte 0x23
.uleb128 0x4
.byte 0x0
.uleb128 0x4
.long .LC13
.byte 0x4
.byte 0x5
.uleb128 0x2
.long 0x133
.long .LC15
.byte 0x8
.byte 0x1
.byte 0x8
.uleb128 0x7
.long .LC16
.byte 0x1
.byte 0x8
.long 0x14d
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x7
.long .LC17
.byte 0x1
.byte 0x8
.long 0x153
.byte 0x2
.byte 0x23
.uleb128 0x4
.byte 0x0
.uleb128 0x9
.long 0x146
.long .LC30
.long 0xbf
.uleb128 0xa
.long 0x146
.byte 0x0
.uleb128 0x4
.long .LC18
.byte 0x4
.byte 0x5
.uleb128 0x8
.byte 0x4
.long 0x133
.uleb128 0x8
.byte 0x4
.long 0xda
.uleb128 0xb
.long 0x185
.long .LC19
.long 0xffffffff
.byte 0x1
.byte 0x8
.uleb128 0x7
.long .LC20
.byte 0x1
.byte 0x8
.long 0xda
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x7
.long .LC21
.byte 0x1
.byte 0x8
.long 0x14d
.byte 0x2
.byte 0x23
.uleb128 0x0
.byte 0x0
.uleb128 0xb
.long 0x1b1
.long .LC22
.long 0xffffffff
.byte 0x1
.byte 0x8
.uleb128 0x7
.long .LC20
.byte 0x1
.byte 0x8
.long 0xda
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x7
.long .LC23
.byte 0x1
.byte 0x8
.long 0x133
.byte 0x2
.byte 0x23
.uleb128 0xb
.byte 0x0
.uleb128 0xc
.byte 0x1
.long .LC46
.byte 0x1
.byte 0xa
.long .LC47
.long .LFB1
.long .LFE1
.byte 0x1
.byte 0x55
.uleb128 0xd
.long .LC10
.long 0x3e
.uleb128 0xd
.long .LC24
.long 0x25
.uleb128 0xd
.long .LC11
.long 0xbf
.uleb128 0xd
.long .LC25
.long 0xc6
.uleb128 0xd
.long .LC26
.long 0xcd
.uleb128 0xd
.long .LC13
.long 0xd3
.uleb128 0xe
.long .LC27
.byte 0x2
.byte 0x1
.long 0x208
.uleb128 0x4
.long .LC27
.byte 0x4
.byte 0x7
.uleb128 0xf
.long .LC28
.uleb128 0xe
.long .LC29
.byte 0x2
.byte 0x1
.long 0x21f
.uleb128 0x9
.long 0x234
.long .LC29
.long 0x234
.uleb128 0x10
.long 0x146
.byte 0x0
.byte 0x5
.byte 0x0
.uleb128 0x4
.long .LC31
.byte 0x4
.byte 0x5
.uleb128 0xe
.long .LC32
.byte 0x2
.byte 0x69
.long 0x246
.uleb128 0x4
.long .LC33
.byte 0x4
.byte 0x7
.uleb128 0xd
.long .LC34
.long 0x256
.uleb128 0x4
.long .LC35
.byte 0x4
.byte 0x7
.uleb128 0xd
.long .LC36
.long 0x133
.uleb128 0xd
.long .LC37
.long 0x26f
.uleb128 0x8
.byte 0x4
.long 0x185
.uleb128 0xd
.long .LC38
.long 0x27e
.uleb128 0x4
.long .LC39
.byte 0x4
.byte 0x7
.uleb128 0xd
.long .LC40
.long 0x28e
.uleb128 0x9
.long 0x2a3
.long .LC41
.long 0xbf
.uleb128 0x10
.long 0x146
.byte 0x1
.byte 0xe
.byte 0x0
.uleb128 0x11
.long .LC48
.byte 0x1
.byte 0x8
.long 0x2b4
.byte 0x5
.byte 0x3
.long no_debug__message
.uleb128 0x12
.long 0x28e
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x10
.uleb128 0x6
.uleb128 0x12
.uleb128 0x1
.uleb128 0x11
.uleb128 0x1
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x13
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0xe
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0xd
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x38
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0x24
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x4
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0xe
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x6
.uleb128 0x28
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1c
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x7
.uleb128 0xd
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x38
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x8
.uleb128 0xf
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x9
.uleb128 0x1
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0xe
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xa
.uleb128 0x21
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xb
.uleb128 0x13
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3
.uleb128 0xe
.uleb128 0xb
.uleb128 0x6
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0xc
.uleb128 0x2e
.byte 0x0
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x2007
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0xd
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xe
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xf
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.byte 0x0
.byte 0x0
.uleb128 0x10
.uleb128 0x21
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.uleb128 0x22
.uleb128 0xb
.uleb128 0x2f
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x11
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x12
.uleb128 0x26
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x20
.value 0x2
.long .Ldebug_info0
.long 0x2ba
.long 0x1b1
.string "no_debug.main"
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x1c
.value 0x2
.long .Ldebug_info0
.byte 0x4
.byte 0x0
.value 0x0
.value 0x0
.long .Ltext0
.long .Letext0-.Ltext0
.long 0x0
.long 0x0
.section .debug_str,"MS",@progbits,1
.LC23:
.string "ARRAY"
.LC10:
.string "long_long_float"
.LC5:
.string "lang"
.LC26:
.string "access_character"
.LC17:
.string "P_BOUNDS"
.LC42:
.string "no_debug.adb"
.LC44:
.string "GNU Ada 3.2 20020330 (experimental)"
.LC38:
.string "no_debug.TTmessageSP1._XDLU_1"
.LC35:
.string "positive___XDLU_1__2147483647"
.LC4:
.string "not_handled_by_others"
.LC48:
.string "no_debug.message"
.LC8:
.string "htable_ptr"
.LC28:
.string "void"
.LC37:
.string "string._XU"
.LC32:
.string "system.address"
.LC24:
.string "long_long_float._PAD"
.LC3:
.string "exception"
.LC9:
.string "import_code"
.LC45:
.string "boolean"
.LC34:
.string "positive._XDLU_1"
.LC47:
.string "main"
.LC16:
.string "P_ARRAY"
.LC12:
.string "natural___XDLU_0__2147483647"
.LC39:
.string "no_debug__TTmessageSP1___XDLU_1__14"
.LC20:
.string "BOUNDS"
.LC41:
.string "no_debug__TmessageS"
.LC0:
.string "false"
.LC19:
.string "string___XUT___XVE"
.LC25:
.string "natural._XDLU_0"
.LC27:
.string "unsigned int"
.LC2:
.string "long_long_float___PAD"
.LC43:
.string "/tmp"
.LC1:
.string "true"
.LC6:
.string "name_length"
.LC40:
.string "no_debug.TmessageS"
.LC30:
.string "string___XUA"
.LC14:
.string "string___XUB"
.LC15:
.string "string___XUP"
.LC22:
.string "string___XUT"
.LC21:
.string "ARRAY._XVL"
.LC46:
.string "no_debug.main"
.LC33:
.string "system__address"
.LC31:
.string "SIGNED_32"
.LC29:
.string "JMPBUF_T"
.LC36:
.string "string._XUA"
.LC7:
.string "full_name"
.LC11:
.string "character"
.LC18:
.string "long int"
.LC13:
.string "integer"
.ident "GCC: (GNU) 3.2 20020330 (experimental)"
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-03-31 2:46 GDB 5.2 vs. Ada (and probably other unknown languages) Florian Weimer
@ 2002-04-03 8:47 ` Andrew Cagney
2002-04-04 21:18 ` Florian Weimer
2002-04-11 14:17 ` Michael Snyder
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2002-04-03 8:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: gdb
> It seems that GDB (starting with 5.1.1 or so) can no longer debug
> programs written in languages unknown to it. With previous GDB
> versions, you could at least set breakpoints, get backtraces, and
> examine most variables, although you had to take name mangling into
> account.
>
> For example, if I try to set a breakpoint in an Ada program, I just
> get the error message "internal error - unimplemented function
> unk_lang_create_fundamental_type called."
>
> Is there a workaround? Even if full Ada support is not available,
> getting backtraces would be helpful in some cases.
Definitly sounds like a new (and unknown) regression :-(
Can you create a bug report to track this
(http://sources.redhat.com/gdb/bugs/). For a workaround, what happens
if you enter ``set language c''?
There is also a source code dropping of ACT's Ada support in:
ftp://sources.redhat.com/pub/gdb/contrib/gnat/ you may find the relevant
change in there.
Andrew
PS: If you're interested in integrating some of the Ada stuff then
you'll probably also need to get copyright (to the fsf) assignment in place.
> Here's a small, stand-alone test program (you have to compile it using
> "gcc -S -g no_debug.adb && gcc no_debug.s", as it doesn't use the Ada
> run-time library).
>
> package No_Debug is
>
> procedure Main;
> pragma Export (C, Main, "main");
>
> end No_Debug;
>
> with System; use System;
>
> package body No_Debug is
>
> procedure Puts (Str : Address);
> pragma Import (C, Puts, "puts");
>
> Message : constant String := "Hello, world!" & ASCII.NUL;
>
> procedure Main is
> begin
> Puts (Message'Address);
> end Main;
>
> end No_Debug;
>
> I've attached the x86 assembler code below, in case you want to
> experiment yourself without having to install Ada.
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-04-03 8:47 ` Andrew Cagney
@ 2002-04-04 21:18 ` Florian Weimer
2002-04-04 21:27 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2002-04-04 21:18 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney <ac131313@cygnus.com> writes:
>> Is there a workaround? Even if full Ada support is not available,
>> getting backtraces would be helpful in some cases.
>
> Definitly sounds like a new (and unknown) regression :-(
> Can you create a bug report to track this
> (http://sources.redhat.com/gdb/bugs/).
Okay.
> For a workaround, what happens if you enter ``set language c''?
The problem persits. It seems to be related to DWARF2. If I compile
using "-gstabs", GDB 5.1.1 works fine.
> There is also a source code dropping of ACT's Ada support in:
> ftp://sources.redhat.com/pub/gdb/contrib/gnat/ you may find the
> relevant change in there.
Aidan Skinner's patch based on this appears to help, too.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-04-04 21:18 ` Florian Weimer
@ 2002-04-04 21:27 ` Daniel Jacobowitz
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Jacobowitz @ 2002-04-04 21:27 UTC (permalink / raw)
To: gdb
On Fri, Apr 05, 2002 at 07:18:39AM +0200, Florian Weimer wrote:
> Andrew Cagney <ac131313@cygnus.com> writes:
>
> >> Is there a workaround? Even if full Ada support is not available,
> >> getting backtraces would be helpful in some cases.
> >
> > Definitly sounds like a new (and unknown) regression :-(
> > Can you create a bug report to track this
> > (http://sources.redhat.com/gdb/bugs/).
>
> Okay.
>
> > For a workaround, what happens if you enter ``set language c''?
>
> The problem persits. It seems to be related to DWARF2. If I compile
> using "-gstabs", GDB 5.1.1 works fine.
That's because stabs doesn't have particularly unique language markers,
I'd imagine. Most places in GDB default to C, but DWARF2 trusts the
object file.
Perhaps if DWARF2 defaults the language to C instead of unknown...
>
> > There is also a source code dropping of ACT's Ada support in:
> > ftp://sources.redhat.com/pub/gdb/contrib/gnat/ you may find the
> > relevant change in there.
>
> Aidan Skinner's patch based on this appears to help, too.
>
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-03-31 2:46 GDB 5.2 vs. Ada (and probably other unknown languages) Florian Weimer
2002-04-03 8:47 ` Andrew Cagney
@ 2002-04-11 14:17 ` Michael Snyder
2002-04-11 14:28 ` Per Bothner
1 sibling, 1 reply; 7+ messages in thread
From: Michael Snyder @ 2002-04-11 14:17 UTC (permalink / raw)
To: Florian Weimer; +Cc: gdb
Florian Weimer wrote:
>
> It seems that GDB (starting with 5.1.1 or so) can no longer debug
> programs written in languages unknown to it. With previous GDB
> versions, you could at least set breakpoints, get backtraces, and
> examine most variables, although you had to take name mangling into
> account.
>
> For example, if I try to set a breakpoint in an Ada program, I just
> get the error message "internal error - unimplemented function
> unk_lang_create_fundamental_type called."
That's bad. GDB should not refuse to debug a source file just because
it doesn't know the language.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-04-11 14:17 ` Michael Snyder
@ 2002-04-11 14:28 ` Per Bothner
2002-04-21 10:50 ` Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Per Bothner @ 2002-04-11 14:28 UTC (permalink / raw)
To: Michael Snyder; +Cc: Florian Weimer, gdb
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Michael Snyder wrote:
>>For example, if I try to set a breakpoint in an Ada program, I just
>>get the error message "internal error - unimplemented function
>>unk_lang_create_fundamental_type called."
>
>
> That's bad. GDB should not refuse to debug a source file just because
> it doesn't know the language.
Could you try this patch:
* language.c (unk_lang_create_fundamental_type): Remove.
(unknown_language_defn, auto_language_defn, local_language_defn):
In place of unk_lang_create_fundamental_type use
c_create_fundamental_type.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/
[-- Attachment #2: lang.diff --]
[-- Type: text/plain, Size: 2186 bytes --]
Index: language.c
===================================================================
RCS file: /cvs/src/src/gdb/language.c,v
retrieving revision 1.23
diff -u -p -r1.23 language.c
--- language.c 28 Mar 2002 01:35:55 -0000 1.23
+++ language.c 11 Apr 2002 21:27:15 -0000
@@ -41,6 +41,7 @@
#include "language.h"
#include "target.h"
#include "parser-defs.h"
+#include "c-lang.h"
#include "jv-lang.h"
extern void _initialize_language (void);
@@ -1416,12 +1417,6 @@ unk_lang_printstr (struct ui_file *strea
error ("internal error - unimplemented function unk_lang_printstr called.");
}
-static struct type *
-unk_lang_create_fundamental_type (struct objfile *objfile, int typeid)
-{
- error ("internal error - unimplemented function unk_lang_create_fundamental_type called.");
-}
-
static void
unk_lang_print_type (struct type *type, char *varstring, struct ui_file *stream,
int show, int level)
@@ -1467,7 +1462,7 @@ const struct language_defn unknown_langu
unk_lang_printchar, /* Print character constant */
unk_lang_printstr,
unk_lang_emit_char,
- unk_lang_create_fundamental_type,
+ c_create_fundamental_type,
unk_lang_print_type, /* Print a type using appropriate syntax */
unk_lang_val_print, /* Print a value using appropriate syntax */
unk_lang_value_print, /* Print a top-level value */
@@ -1497,7 +1492,7 @@ const struct language_defn auto_language
unk_lang_printchar, /* Print character constant */
unk_lang_printstr,
unk_lang_emit_char,
- unk_lang_create_fundamental_type,
+ c_create_fundamental_type,
unk_lang_print_type, /* Print a type using appropriate syntax */
unk_lang_val_print, /* Print a value using appropriate syntax */
unk_lang_value_print, /* Print a top-level value */
@@ -1526,7 +1521,7 @@ const struct language_defn local_languag
unk_lang_printchar, /* Print character constant */
unk_lang_printstr,
unk_lang_emit_char,
- unk_lang_create_fundamental_type,
+ c_create_fundamental_type,
unk_lang_print_type, /* Print a type using appropriate syntax */
unk_lang_val_print, /* Print a value using appropriate syntax */
unk_lang_value_print, /* Print a top-level value */
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: GDB 5.2 vs. Ada (and probably other unknown languages)
2002-04-11 14:28 ` Per Bothner
@ 2002-04-21 10:50 ` Florian Weimer
0 siblings, 0 replies; 7+ messages in thread
From: Florian Weimer @ 2002-04-21 10:50 UTC (permalink / raw)
To: Per Bothner; +Cc: Michael Snyder, gdb
Per Bothner <per@bothner.com> writes:
> Michael Snyder wrote:
>> That's bad. GDB should not refuse to debug a source file just
>> because it doesn't know the language.
>
> Could you try this patch:
>
> * language.c (unk_lang_create_fundamental_type): Remove.
> (unknown_language_defn, auto_language_defn, local_language_defn):
> In place of unk_lang_create_fundamental_type use
> c_create_fundamental_type.
Thanks, it seems to work, at least I can set breakpoints now and
access variables (with suitable type casts, of course).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-04-21 17:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-31 2:46 GDB 5.2 vs. Ada (and probably other unknown languages) Florian Weimer
2002-04-03 8:47 ` Andrew Cagney
2002-04-04 21:18 ` Florian Weimer
2002-04-04 21:27 ` Daniel Jacobowitz
2002-04-11 14:17 ` Michael Snyder
2002-04-11 14:28 ` Per Bothner
2002-04-21 10:50 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox