[PATCH] Add d_main_name to dlang.c

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Add d_main_name to dlang.c

Iain Buclaw
Hi,

This is the first patch of a few that will eventually get sent across
as I write them.  Adds support for gdb to discover the source location
of D main function.

Regards,
Iain.

dmain-name.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Tom Tromey
>>>>> "Iain" == Iain Buclaw <[hidden email]> writes:

Iain> +2013-11-18  Iain Buclaw  <[hidden email]>
Iain> +
Iain> + * d-lang.h (d_main_name): Add declaration.
Iain> + * d-lang.c (d_main_name): New function.
Iain> + * symtab.c (find_main_name): Add call to d_main_name.

Looks good to me.

Do you have a copyright assignment on file?
If not, contact me off-list and I'll get you started.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Iain Buclaw
On 19 November 2013 15:52, Tom Tromey <[hidden email]> wrote:

>>>>>> "Iain" == Iain Buclaw <[hidden email]> writes:
>
> Iain> +2013-11-18  Iain Buclaw  <[hidden email]>
> Iain> +
> Iain> + * d-lang.h (d_main_name): Add declaration.
> Iain> + * d-lang.c (d_main_name): New function.
> Iain> + * symtab.c (find_main_name): Add call to d_main_name.
>
> Looks good to me.
>
> Do you have a copyright assignment on file?
> If not, contact me off-list and I'll get you started.
>
> Tom

By the way, it is more preferable to use the mangled name of the D
main function (_Dmain), or the pretty debug de-mangled name?  Both
work just as well in achieving the job.


Regards
Iain
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Tom Tromey
>>>>> "Iain" == Iain Buclaw <[hidden email]> writes:

Iain> By the way, it is more preferable to use the mangled name of the D
Iain> main function (_Dmain), or the pretty debug de-mangled name?  Both
Iain> work just as well in achieving the job.

I don't think it matters.

I forgot to ask for a test case.  There really should be one.

Tom
Reply | Threaded
Open this post in threaded view
|

RE: [PATCH] Add d_main_name to dlang.c

Pierre Muller-5


> -----Message d'origine-----
> De : [hidden email] [mailto:gdb-patches-
> [hidden email]] De la part de Tom Tromey
> Envoyé : mardi 19 novembre 2013 15:49
> À : Iain Buclaw
> Cc : [hidden email]
> Objet : Re: [PATCH] Add d_main_name to dlang.c
>
> >>>>> "Iain" == Iain Buclaw <[hidden email]> writes:
>
> Iain> By the way, it is more preferable to use the mangled name of the
> D
> Iain> main function (_Dmain), or the pretty debug de-mangled name?
> Both
> Iain> work just as well in achieving the job.
>
> I don't think it matters.

  I thought that in general, using the mangled name
would allow to find main even if you do not generate
any debug information, as long as you do not remove the
assembler symbols from the executable.
  This seems like a valid reason to prefer mangled name
over demangled, no?

Pierre
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Tom Tromey
In reply to this post by Tom Tromey
Pierre>   I thought that in general, using the mangled name
Pierre> would allow to find main even if you do not generate
Pierre> any debug information, as long as you do not remove the
Pierre> assembler symbols from the executable.
Pierre>   This seems like a valid reason to prefer mangled name
Pierre> over demangled, no?

The demangled name ends up in the minimal symbol table as well.
It's convoluted but it ends up in symbol_find_demangled_name, which has
a case for language_d.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Iain Buclaw
On 19 November 2013 21:03, Tom Tromey <[hidden email]> wrote:

> Pierre>   I thought that in general, using the mangled name
> Pierre> would allow to find main even if you do not generate
> Pierre> any debug information, as long as you do not remove the
> Pierre> assembler symbols from the executable.
> Pierre>   This seems like a valid reason to prefer mangled name
> Pierre> over demangled, no?
>
> The demangled name ends up in the minimal symbol table as well.
> It's convoluted but it ends up in symbol_find_demangled_name, which has
> a case for language_d.
>
> Tom
Hi Tom,

(I've just realised that I my last reply was not cc'd into gdb-patches)

The assignments should now be processed.

Since November, I've made a few more changes that are reflected in
this new patch.

I would add some more tests for D, but I feel that should write a
complete parser for D expressions first (d-exp.y) - this will be done
at a later date.

Regards
Iain.

dsupport.patch (74K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Iain Buclaw
On 3 January 2014 18:18, Iain Buclaw <[hidden email]> wrote:

> On 19 November 2013 21:03, Tom Tromey <[hidden email]> wrote:
>> Pierre>   I thought that in general, using the mangled name
>> Pierre> would allow to find main even if you do not generate
>> Pierre> any debug information, as long as you do not remove the
>> Pierre> assembler symbols from the executable.
>> Pierre>   This seems like a valid reason to prefer mangled name
>> Pierre> over demangled, no?
>>
>> The demangled name ends up in the minimal symbol table as well.
>> It's convoluted but it ends up in symbol_find_demangled_name, which has
>> a case for language_d.
>>
>> Tom
>
> Hi Tom,
>
> (I've just realised that I my last reply was not cc'd into gdb-patches)
>
> The assignments should now be processed.
>
> Since November, I've made a few more changes that are reflected in
> this new patch.
>
> I would add some more tests for D, but I feel that should write a
> complete parser for D expressions first (d-exp.y) - this will be done
> at a later date.
>

By the way, would it be best to split this up into smaller changes?

Regards
Iain.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Add d_main_name to dlang.c

Joel Brobecker
> By the way, would it be best to split this up into smaller changes?

If they can and should be applied independently, most definitely.
This has two strong advantages I can think of:
  - In case problem requiring a revert (I am not speaking of your
    patch!), it allows us to revert the one patch that causes problem,
    while keepping the rest;
  - It makes it much easier to review the patches, first because
    they are easier to digest, and second because we can review
    them one at a time, making it more likely for us to find the time
    to do so.

--
Joel