On 3/27/20 3:21 PM, Jeff Law wrote:
On Fri, 2020-03-27 at 10:10 +0100, Martin Liška wrote:
On 3/26/20 5:54 PM, Jeff Law wrote:
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Wh
On Fri, 2020-03-27 at 10:10 +0100, Martin Liška wrote:
> On 3/26/20 5:54 PM, Jeff Law wrote:
> > On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> > > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > > We nee to support different variables, like TLS, data and bss variables.
> > >
> > > Why do we nee
On 3/26/20 5:54 PM, Jeff Law wrote:
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
About BSS and DATA I a
On Mon, 2020-03-09 at 17:56 +0100, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> About BSS and DATA I agree that it would be handy
On Thu, Mar 19, 2020 at 12:56 PM Richard Biener
wrote:
>
> On March 19, 2020 5:51:14 PM GMT+01:00, "H.J. Lu" wrote:
> >On Thu, Mar 19, 2020 at 9:00 AM Martin Liška wrote:
> >>
> >> On 3/19/20 4:50 PM, H.J. Lu wrote:
> >> > I like it and I will take case of binutils side.
> >> >
> >> > Thanks.
>
On March 19, 2020 5:51:14 PM GMT+01:00, "H.J. Lu" wrote:
>On Thu, Mar 19, 2020 at 9:00 AM Martin Liška wrote:
>>
>> On 3/19/20 4:50 PM, H.J. Lu wrote:
>> > I like it and I will take case of binutils side.
>> >
>> > Thanks.
>>
>> Great. I've just installed the 2 patches to master.
>>
>
>Here is th
On Thu, Mar 19, 2020 at 9:00 AM Martin Liška wrote:
>
> On 3/19/20 4:50 PM, H.J. Lu wrote:
> > I like it and I will take case of binutils side.
> >
> > Thanks.
>
> Great. I've just installed the 2 patches to master.
>
Here is the binutils patch:
https://sourceware.org/pipermail/binutils/2020-Mar
On 3/19/20 4:50 PM, H.J. Lu wrote:
I like it and I will take case of binutils side.
Thanks.
Great. I've just installed the 2 patches to master.
Martin
On Thu, Mar 19, 2020 at 8:46 AM Richard Biener
wrote:
>
> On Thu, Mar 19, 2020 at 4:00 PM Martin Liška wrote:
> >
> > On 3/19/20 10:12 AM, Richard Biener wrote:
> > > On Wed, Mar 18, 2020 at 9:52 AM Martin Liška wrote:
> > >>
> > >> On 3/18/20 12:27 AM, Jan Hubicka wrote:
> > Hi.
> >
>
On Thu, Mar 19, 2020 at 4:00 PM Martin Liška wrote:
>
> On 3/19/20 10:12 AM, Richard Biener wrote:
> > On Wed, Mar 18, 2020 at 9:52 AM Martin Liška wrote:
> >>
> >> On 3/18/20 12:27 AM, Jan Hubicka wrote:
> Hi.
>
> There's updated version of the patch.
> Changes from the previ
On 3/19/20 10:12 AM, Richard Biener wrote:
On Wed, Mar 18, 2020 at 9:52 AM Martin Liška wrote:
On 3/18/20 12:27 AM, Jan Hubicka wrote:
Hi.
There's updated version of the patch.
Changes from the previous version:
- comment added to ld_plugin_symbol
- new section renamed to ext_symtab
- assert
On Wed, Mar 18, 2020 at 9:52 AM Martin Liška wrote:
>
> On 3/18/20 12:27 AM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> There's updated version of the patch.
> >> Changes from the previous version:
> >> - comment added to ld_plugin_symbol
> >> - new section renamed to ext_symtab
> >> - assert added for
On 3/18/20 12:27 AM, Jan Hubicka wrote:
Hi.
There's updated version of the patch.
Changes from the previous version:
- comment added to ld_plugin_symbol
- new section renamed to ext_symtab
- assert added for loop iterations in produce_symtab and
produce_symtab_extension
Hi,
I hope this is last
> Hi.
>
> There's updated version of the patch.
> Changes from the previous version:
> - comment added to ld_plugin_symbol
> - new section renamed to ext_symtab
> - assert added for loop iterations in produce_symtab and
> produce_symtab_extension
Hi,
I hope this is last version of the patch.
>
>
On 3/16/20 3:34 PM, H.J. Lu wrote:
It is LDPT_ADD_SYMBOLS_V2, not LDPT_GET_SYMBOLS_V2.
Sorry. It's fixed now.
Martin
On Mon, Mar 16, 2020 at 6:50 AM Martin Liška wrote:
>
> On 3/16/20 12:12 PM, H.J. Lu wrote:
> > (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and
> > ^^^ Typo,
>
> Thank you. I fixed that in my development branch.
Still not right. It should
On 3/16/20 12:12 PM, H.J. Lu wrote:
(enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V and
^^^ Typo,
Thank you. I fixed that in my development branch.
Martin
On Thu, Mar 12, 2020 at 7:54 AM Martin Liška wrote:
>
> Hi.
>
> There's updated version of the patch.
> Changes from the previous version:
> - comment added to ld_plugin_symbol
> - new section renamed to ext_symtab
> - assert added for loop iterations in produce_symtab and
> produce_symtab_extens
Hi.
There's updated version of the patch.
Changes from the previous version:
- comment added to ld_plugin_symbol
- new section renamed to ext_symtab
- assert added for loop iterations in produce_symtab and
produce_symtab_extension
Martin
>From ad24565cfb3166fdd9995381b25c1f558c7bcf8c Mon Sep 17
On 3/12/20 2:15 PM, Richard Biener wrote:
#elif defined __LITTLE_ENDIAN__
Hmm, the macro is not defined. Even a simple test-case shows that:
$ cat le.c
#ifdef __LITTLE_ENDIAN__
asdfa
#endif
$ gcc le.c -c
[no error]
On Thu, Mar 12, 2020 at 2:11 PM Martin Liška wrote:
>
> On 3/12/20 1:55 PM, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> 2020-03-12 Martin Liska
> >>
> >> * lto-section-in.c: Add extension_symtab.
> >> * lto-streamer-out.c (write_symbol_extension_info):
> >> New.
> >> (p
On 3/12/20 1:55 PM, Jan Hubicka wrote:
gcc/ChangeLog:
2020-03-12 Martin Liska
* lto-section-in.c: Add extension_symtab.
* lto-streamer-out.c (write_symbol_extension_info):
New.
(produce_symtab_extension): New.
(produce_asm_for_decls): Stream also produ
> gcc/ChangeLog:
>
> 2020-03-12 Martin Liska
>
> * lto-section-in.c: Add extension_symtab.
> * lto-streamer-out.c (write_symbol_extension_info):
> New.
> (produce_symtab_extension): New.
> (produce_asm_for_decls): Stream also produce_symtab_extension.
> * lt
Hi.
I'm sending extended version of the patch where I address Honza's note
about backward compatibility. So I add a next section _lto.extension_symtab
where I put new bits. With that, new LTO bytecode can be opened with older
LTO plugin.
Moreover, I've also tested lto.exp tests and binutils mast
On Wed, 11 Mar 2020, Martin Liška wrote:
> > Is there a comprehensive list of plugins out in the wild using the LD
> > plugin API?
>
> I know only about:
> $ ls /usr/lib/bfd-plugins
> liblto_plugin.so.0.0.0 LLVMgold.so
>
> and I know about Alexander Monakov (some dead code elimination plug-in).
On 3/11/20 1:51 PM, Richard Biener wrote:
Splitting an existing field isn't hackish IMHO. I guess even
explicitely changing it
to one short and two char fields would be OK.
Good, I'm doing that in the updated version of that patch.
H.J. is right now working on the corresponding binutils counte
On 3/11/20 2:24 PM, H.J. Lu wrote:
ld-new don't have to use the new interface since it isn't needed.
Yeah. We talk about nm that should utilize the new API, right?
Martin
On Wed, Mar 11, 2020 at 6:09 AM Martin Liška wrote:
>
> On 3/11/20 1:51 PM, Richard Biener wrote:
> > I'm not sure I understand the versioning, we should aim at something where
> > an updated plugin can talk to old and new ld and where a new ld can also
> > talk
> > to an old plugin. That requir
On 3/11/20 1:51 PM, Richard Biener wrote:
I'm not sure I understand the versioning, we should aim at something where
an updated plugin can talk to old and new ld and where a new ld can also talk
to an old plugin. That requires an arbitration which I don't see implemented?
So ld-new will set ne
On Wed, Mar 11, 2020 at 1:22 PM Martin Liška wrote:
>
> On 3/11/20 11:22 AM, Richard Biener wrote:
> > On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote:
> >>
> >> On 3/10/20 1:07 PM, Martin Liška wrote:
> >>> On 3/10/20 12:24 PM, Richard Biener wrote:
> Not sure how symtab is encoded righ
On 3/11/20 11:22 AM, Richard Biener wrote:
On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote:
On 3/10/20 1:07 PM, Martin Liška wrote:
On 3/10/20 12:24 PM, Richard Biener wrote:
Not sure how symtab is encoded right now but we also could have
Ok, right now I don't see symtab entry much ext
On Wed, Mar 11, 2020 at 11:22 AM Richard Biener
wrote:
>
> On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote:
> >
> > On 3/10/20 1:07 PM, Martin Liška wrote:
> > > On 3/10/20 12:24 PM, Richard Biener wrote:
> > >> Not sure how symtab is encoded right now but we also could have
> > >
> > > Ok, r
On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote:
>
> On 3/10/20 1:07 PM, Martin Liška wrote:
> > On 3/10/20 12:24 PM, Richard Biener wrote:
> >> Not sure how symtab is encoded right now but we also could have
> >
> > Ok, right now I don't see symtab entry much extensible.
> >
> > But what am I
On 3/10/20 1:07 PM, Martin Liška wrote:
On 3/10/20 12:24 PM, Richard Biener wrote:
Not sure how symtab is encoded right now but we also could have
Ok, right now I don't see symtab entry much extensible.
But what am I suggesting is to parse LTO bytecode version and then
process conditional par
Hello,
On Tue, 10 Mar 2020, Martin Liška wrote:
> >>> We nee to support different variables, like TLS, data and bss variables.
> >>
> >> Why do we need TLS? Right now, it's not supported by nm.
> >
> > Of course it does. It's the 'T' (or 't') character.
>
> Thank you reply!
>
> Are you sure a
On 3/10/20 10:39 AM, Martin Liška wrote:
Are you sure about it?
$ gcc gcc/testsuite/gcc.target/i386/pr56564-3.c -c -fpic && nm pr56564-3.o
...
D s
0010 D t
?
A nicer example:
$ cat tls.c
__thread struct S { long a, b; } s = { 0, 0 };
__thread char t[16] = { 7 };
On 3/10/20 12:24 PM, Richard Biener wrote:
Not sure how symtab is encoded right now but we also could have
Ok, right now I don't see symtab entry much extensible.
But what am I suggesting is to parse LTO bytecode version and then
process conditional parsing of lto_symtab section.
Thoughts?
Ma
On Tue, Mar 10, 2020 at 12:09 PM Jan Hubicka wrote:
>
> > > >>> @Honza/Richi: Do you have any opinion about that?
> > > >
> > > > I guess we indeed want to get as close to non-LTO nm behaviour as
> > > > possible. So we want to support them and perhaps think of .symtab
> > > > section file format
> > >>> @Honza/Richi: Do you have any opinion about that?
> > >
> > > I guess we indeed want to get as close to non-LTO nm behaviour as
> > > possible. So we want to support them and perhaps think of .symtab
> > > section file format that can be made backward compatible (such as having
> > > attrib
On Tue, Mar 10, 2020 at 11:05 AM Martin Liška wrote:
>
> On 3/9/20 9:19 PM, Jan Hubicka wrote:
> >> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
> >>>
> >>> On 3/9/20 4:36 PM, H.J. Lu wrote:
> We nee to support different variables, like TLS, data and bss variables.
> >>>
> >>> Why do w
On 3/9/20 9:19 PM, Jan Hubicka wrote:
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introdu
On 3/9/20 8:45 PM, Michael Matz wrote:
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't
> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
> >
> > On 3/9/20 4:36 PM, H.J. Lu wrote:
> > > We nee to support different variables, like TLS, data and bss variables.
> >
> > Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
>
> Since you are introducing symbol types,
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't') character. When you introduce
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
>
> On 3/9/20 4:36 PM, H.J. Lu wrote:
> > We nee to support different variables, like TLS, data and bss variables.
>
> Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introducing symbol types, why not support
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
About BSS and DATA I agree that it would be handy. I can theoretically
covered with code in get_variable_section/bs
On Mon, Mar 9, 2020 at 2:30 AM Martin Liška wrote:
>
> Hi.
>
> With change of -fno-common default for GCC 10 we're facing serious
> problem with LTO where one can't distinguish in between global symbols
> and variables based on the output of nm:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25
Hi.
With change of -fno-common default for GCC 10 we're facing serious
problem with LTO where one can't distinguish in between global symbols
and variables based on the output of nm:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
$ cat nm.c
char nm_test_var;
$ gcc-9 nm.c -c -fno-common
$
48 matches
Mail list logo
