Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #148298 > unrolled thread

Discarding unneeded object files

Back to article view | Back to comp.lang.c

Contents

  Discarding unneeded object files Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-29 10:36 -0800
    Re: Discarding unneeded object files Bart <bc@freeuk.com> - 2019-11-29 19:29 +0000
      Re: Discarding unneeded object files Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-12-01 05:13 -0800
        Re: Discarding unneeded object files gazelle@shell.xmission.com (Kenny McCormack) - 2019-12-01 14:52 +0000
          Re: Discarding unneeded object files Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-12-01 07:01 -0800
            Re: Discarding unneeded object files gazelle@shell.xmission.com (Kenny McCormack) - 2019-12-01 15:06 +0000
            Re: Discarding unneeded object files Richard Damon <Richard@Damon-Family.org> - 2019-12-01 19:32 -0500
              Re: Discarding unneeded object files Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-12-02 00:00 -0800
          Re: Discarding unneeded object files David Brown <david.brown@hesbynett.no> - 2019-12-01 17:17 +0100
    Re: Discarding unneeded object files Richard Damon <Richard@Damon-Family.org> - 2019-11-29 14:30 -0500
    Re: Discarding unneeded object files jacobnavia <jacob@jacob.remcomp.fr> - 2019-11-30 23:44 +0100
    Re: Discarding unneeded object files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-01 08:42 +0000
      Re: Discarding unneeded object files Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-12-01 05:10 -0800
        Re: Discarding unneeded object files gazelle@shell.xmission.com (Kenny McCormack) - 2019-12-01 14:51 +0000
        Re: Discarding unneeded object files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-01 17:26 +0000
          Re: Discarding unneeded object files gazelle@shell.xmission.com (Kenny McCormack) - 2019-12-01 17:43 +0000
            Re: Discarding unneeded object files Richard Damon <Richard@Damon-Family.org> - 2019-12-01 20:04 -0500
      Re: Discarding unneeded object files Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-01 09:39 -0800
        Re: Discarding unneeded object files gazelle@shell.xmission.com (Kenny McCormack) - 2019-12-01 17:45 +0000
        Re: Discarding unneeded object files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-02 13:15 +0000
          Re: Discarding unneeded object files Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-06 22:05 -0800

Page 1 of 2  [1] 2  Next page →

#148298 — Discarding unneeded object files

I have a 3rd party library which is 50 - 100 source files.

I compile this library to produce a static shared library. All of the object files are gathered together into an archive (In Linux, this is a ".a" file).

I then write my own program which links with this static library. For example:

    gcc main.c -o program -l:libmonkey.a

When the GNU linker links my own program with the archive file, it only links with the object files inside the archive which are needed.

If I had not created the archive file... If I had simply linked my own program with all of the 50-100 object files, then my program would have linked with every single object file -- possibly resulting in unreachable code in the output binary.

So... when the linker links with an archive file, it is smart enough to know which object files are needed, and which are not needed.

Is there any way to get a list of which object files are actually needed when a program links with an archive file? If I can get such a list, I can remove the redundant object files from the project, and then go on to tweak the object files that are actually needed.

I need to reduce a library of nearly a hundred source files, to about ten source files, and then go through each of these 10 source files an apply __attribute__ to every function. 

[toc] | [next] | [standalone]

#148299

On 29/11/2019 18:36, Frederick Gotham wrote:
> I have a 3rd party library which is 50 - 100 source files.
> 
> I compile this library to produce a static shared library. All of the object files are gathered together into an archive (In Linux, this is a ".a" file).
> 
> I then write my own program which links with this static library. For example:
> 
>      gcc main.c -o program -l:libmonkey.a
> 
> When the GNU linker links my own program with the archive file, it only links with the object files inside the archive which are needed.
> 
> If I had not created the archive file... If I had simply linked my own program with all of the 50-100 object files, then my program would have linked with every single object file -- possibly resulting in unreachable code in the output binary.
> 
> So... when the linker links with an archive file, it is smart enough to know which object files are needed, and which are not needed.
> 
> Is there any way to get a list of which object files are actually needed when a program links with an archive file? If I can get such a list, I can remove the redundant object files from the project, and then go on to tweak the object files that are actually needed.
> 
> I need to reduce a library of nearly a hundred source files, to about ten source files, and then go through each of these 10 source files an apply __attribute__ to every function.
> 

Wasn't your intention to make it hard to hack? Then having redundant 
modules could make it harder for a hacker.

[toc] | [prev] | [next] | [standalone]

#148320

"Wasn't your intention to make it hard to hack? Then having redundant
modules could make it harder for a hacker."


I understand your rationale here, but I don't want to manually go through a hundred source files to mark every function "always_inline" and "flatten". So first I remove the redundant files to reduce 100 to 10.

After I've marked the necessary functions as "always_inline" and "flatten", I can then later add in redundant code.

[toc] | [prev] | [next] | [standalone]

#148322

In article <d7db9b30-1aa5-4369-8978-96a7aa9b385d@googlegroups.com>,
Frederick Gotham  <cauldwell.thomas@gmail.com> wrote:
>"Wasn't your intention to make it hard to hack? Then having redundant
>modules could make it harder for a hacker."
>
>
>I understand your rationale here, but I don't want to manually go through a
>hundred source files to mark every function "always_inline" and "flatten". So
>first I remove the redundant files to reduce 100 to 10.
>
>After I've marked the necessary functions as "always_inline" and "flatten", I can
>then later add in redundant code.

Can't you write a script to do this - whatever it is you're doing?

Surely, that's the way to go - and then it won't matter how many times you
have to do it.

-- 
Which of these is the crazier bit of right wing lunacy?
1) We've just had another mass shooting; now is not the time to be talking about gun control.

2) We've just had a massive hurricane; now is not the time to be talking about climate change.

[toc] | [prev] | [next] | [standalone]

#148323

"Can't you write a script to do this - whatever it is you're doing?"


It wouldn't be totally straight forward.

First I would have to scan the source file to find function definitions. I would have to create a function declaration right before the function definition, and add the attributes to the declaration (as you can't add attributes to a definition).

Parsing a function definition in C might not be too much work, but parsing a function definition in C++ could get a bit hairy with trailing return types and so forth.

[toc] | [prev] | [next] | [standalone]

#148324

In article <f5633d78-4e5b-498c-adbd-a7ff33f9bca2@googlegroups.com>,
Frederick Gotham  <cauldwell.thomas@gmail.com> wrote:
>"Can't you write a script to do this - whatever it is you're doing?"
>
>
>It wouldn't be totally straight forward.
>
>First I would have to scan the source file to find function
>definitions. I would have to create a function declaration right before
>the function definition, and add the attributes to the declaration (as
>you can't add attributes to a definition).
>
>Parsing a function definition in C might not be too much work, but
>parsing a function definition in C++ could get a bit hairy with
>trailing return types and so forth.

I get that, but there are a lot of tools out there already that do his sort
of thing.  You could use one of them to do the hard part  - finding the
function definitions - then layer your part on top of that.

Incidentally, if your problem/issue/use-case is C++, then you're off-topic
here...

-- 
Note that Oprah actually is all the things that The Donald only wishes he were.
For one thing, she actually *is* a billionaire.  She's also actually self-made,
came from nothing, knows how to run businesses, never went bankrupt, is smart
and is mentally stable.

[toc] | [prev] | [next] | [standalone]

#148334

On 12/1/19 10:01 AM, Frederick Gotham wrote:
> "Can't you write a script to do this - whatever it is you're doing?"
> 
> 
> It wouldn't be totally straight forward.
> 
> First I would have to scan the source file to find function definitions. I would have to create a function declaration right before the function definition, and add the attributes to the declaration (as you can't add attributes to a definition).
> 
> Parsing a function definition in C might not be too much work, but parsing a function definition in C++ could get a bit hairy with trailing return types and so forth.
> 

I am not sure about the attributes you are wanting to add, but I often
add attributes to functions without making a declaration. I just put a
line before the function something like

__attribute__((my attribute))
void myfunction() {
 ...function code...
}

[toc] | [prev] | [next] | [standalone]

#148338

On Monday, December 2, 2019 at 12:32:55 AM UTC, Richard Damon wrote:

> I am not sure about the attributes you are wanting to add, but I often
> add attributes to functions without making a declaration. I just put a
> line before the function something like
> 
> __attribute__((my attribute))
> void myfunction() {
>  ...function code...
> }


Gcc gives me an error for this.

[toc] | [prev] | [next] | [standalone]

#148325

On 01/12/2019 15:52, Kenny McCormack wrote:
> In article <d7db9b30-1aa5-4369-8978-96a7aa9b385d@googlegroups.com>,
> Frederick Gotham  <cauldwell.thomas@gmail.com> wrote:
>> "Wasn't your intention to make it hard to hack? Then having redundant
>> modules could make it harder for a hacker."
>>
>>
>> I understand your rationale here, but I don't want to manually go through a
>> hundred source files to mark every function "always_inline" and "flatten". So
>> first I remove the redundant files to reduce 100 to 10.
>>
>> After I've marked the necessary functions as "always_inline" and "flatten", I can
>> then later add in redundant code.
> 
> Can't you write a script to do this - whatever it is you're doing?
> 
> Surely, that's the way to go - and then it won't matter how many times you
> have to do it.
> 

Of course that would be a better idea.

An even better idea would be to listen to the advice he gets on the 
newsgroups he posts to.  A few gcc options are all he needs to handle 
everything automatically.  However, he is convinced that his plan is 
good no matter what anyone else says.  I just hope he is joking about 
the need for security or secrecy in his code - or that someone else 
involved realises what whatever the question might be, this guy's 
approach is not the answer.

[toc] | [prev] | [next] | [standalone]

#148300

On 11/29/19 1:36 PM, Frederick Gotham wrote:
> I have a 3rd party library which is 50 - 100 source files.
> 
> I compile this library to produce a static shared library. All of the object files are gathered together into an archive (In Linux, this is a ".a" file).
> 
> I then write my own program which links with this static library. For example:
> 
>     gcc main.c -o program -l:libmonkey.a
> 
> When the GNU linker links my own program with the archive file, it only links with the object files inside the archive which are needed.
> 
> If I had not created the archive file... If I had simply linked my own program with all of the 50-100 object files, then my program would have linked with every single object file -- possibly resulting in unreachable code in the output binary.
> 
> So... when the linker links with an archive file, it is smart enough to know which object files are needed, and which are not needed.
> 
> Is there any way to get a list of which object files are actually needed when a program links with an archive file? If I can get such a list, I can remove the redundant object files from the project, and then go on to tweak the object files that are actually needed.
> 
> I need to reduce a library of nearly a hundred source files, to about ten source files, and then go through each of these 10 source files an apply __attribute__ to every function. 
> 

Libraries/archive files naturally need to be only selectively loaded, as
typically there are many functions in a general library than a given
program will use.

By default, I believe the gnu loader includes all object files
explicitly listed, assuming that you built that list for a reason, so it
assumes you have a reason for specifying them.

If you add the options -ffunction-sections and -fdata-sections when you
compile, the compiler will divide each file into seperate sections for
each function/file scope data object, and then if you link with
--gc-sections it will remove any sections not needed in the final program.

I think there is also an option to list what has been stripped, but I
don't have that handy at the moment.

[toc] | [prev] | [next] | [standalone]

#148314

Le 29/11/2019 à 19:36, Frederick Gotham a écrit :
> I have a 3rd party library which is 50 - 100 source files.
> 
> I compile this library to produce a static shared library. All of the object files are gathered together into an archive (In Linux, this is a ".a" file).
> 
> I then write my own program which links with this static library. For example:
> 
>      gcc main.c -o program -l:libmonkey.a
> 
> When the GNU linker links my own program with the archive file, it only links with the object files inside the archive which are needed.
> 
> If I had not created the archive file... If I had simply linked my own program with all of the 50-100 object files, then my program would have linked with every single object file -- possibly resulting in unreachable code in the output binary.
> 
> So... when the linker links with an archive file, it is smart enough to know which object files are needed, and which are not needed.
> 
> Is there any way to get a list of which object files are actually needed when a program links with an archive file? If I can get such a list, I can remove the redundant object files from the project, and then go on to tweak the object files that are actually needed.
> 
> I need to reduce a library of nearly a hundred source files, to about ten source files, and then go through each of these 10 source files an apply __attribute__ to every function.
> 

You should add the option -M or --print_map to the linker command line. 
This option will generate a listing of all the addresses of all the 
functions in the executable with their correspoçnding OBJECT FILE, so 
you can read the list of object files used very easily.

jacob

[toc] | [prev] | [next] | [standalone]

#148318

On Fri, 2019-11-29, Frederick Gotham wrote:
> I have a 3rd party library which is 50 - 100 source files.
...

You also posted this to comp.lang.c++. Please don't multipost!

It's better to cross-post, i.e. send the same posting to both groups.
That way a c.l.c reader can see that a c.l.c++ responded and save
himself the trouble, or maybe clarify.  You get better answers, and
everyone else wastes less time repeating the same information.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#148319

"You also posted this to comp.lang.c++. Please don't multipost!"

Looks like you're adverse to multi-posting.

I have found that people who are adverse to cross-posting greatly outnumber those who are adverse to multi-posting.

Aiming to achieve while my objective while causing the minimal offense, I multi-posted.

[toc] | [prev] | [next] | [standalone]

#148321

In article <96303078-6b6e-48c3-acf4-b62c62dffe79@googlegroups.com>,
Frederick Gotham  <cauldwell.thomas@gmail.com> wrote:
>"You also posted this to comp.lang.c++. Please don't multipost!"
>
>Looks like you're adverse to multi-posting.
>
>I have found that people who are adverse to cross-posting greatly
>outnumber those who are adverse to multi-posting.
>
>Aiming to achieve while my objective while causing the minimal offense,
>I multi-posted.

Yes, agree. I think you are absolutely right to multi-post.

Note that the guy who slagged you for doing so is a known Usenet jerk-off.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/IceCream

[toc] | [prev] | [next] | [standalone]

#148326

Frederick Gotham <cauldwell.thomas@gmail.com> writes:

> "You also posted this to comp.lang.c++. Please don't multipost!"
>
> Looks like you're adverse to multi-posting.
>
> I have found that people who are adverse to cross-posting greatly
> outnumber those who are adverse to multi-posting.

Cross-posting has got a bad name because it is used by disruptive
posters to spray junk about as widely as possible, and cross-posting to
comp.lang.c and comp.lang.c++ can be a problem when the issue is one
where the languages diverge.  But neither is the case here.  In fact
your post is not really a question about either language.

It's always a judgement call about the circumstances, but when you judge
that a post is equally topical in more than one group, cross-posting is
the way to go.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148329

In article <87r21oyn2c.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>Frederick Gotham <cauldwell.thomas@gmail.com> writes:
>
>> "You also posted this to comp.lang.c++. Please don't multipost!"
>>
>> Looks like you're adverse to multi-posting.
>>
>> I have found that people who are adverse to cross-posting greatly
>> outnumber those who are adverse to multi-posting.
>
>Cross-posting has got a bad name because it is used by disruptive
>posters to spray junk about as widely as possible, and cross-posting to
>comp.lang.c and comp.lang.c++ can be a problem when the issue is one
>where the languages diverge.  But neither is the case here.  In fact
>your post is not really a question about either language.
>
>It's always a judgement call about the circumstances, but when you judge
>that a post is equally topical in more than one group, cross-posting is
>the way to go.

Wrong.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/RoyDeLoon

[toc] | [prev] | [next] | [standalone]

#148335

On 12/1/19 12:43 PM, Kenny McCormack wrote:
> In article <87r21oyn2c.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>> Frederick Gotham <cauldwell.thomas@gmail.com> writes:
>>
>>> "You also posted this to comp.lang.c++. Please don't multipost!"
>>>
>>> Looks like you're adverse to multi-posting.
>>>
>>> I have found that people who are adverse to cross-posting greatly
>>> outnumber those who are adverse to multi-posting.
>>
>> Cross-posting has got a bad name because it is used by disruptive
>> posters to spray junk about as widely as possible, and cross-posting to
>> comp.lang.c and comp.lang.c++ can be a problem when the issue is one
>> where the languages diverge.  But neither is the case here.  In fact
>> your post is not really a question about either language.
>>
>> It's always a judgement call about the circumstances, but when you judge
>> that a post is equally topical in more than one group, cross-posting is
>> the way to go.
> 
> Wrong.
> 

I disagree with the disagreement. The protocol used in Usenet was
designed to support cross-posting, and it is generally the preferred
behavior when posting a question to multiple groups when the question is
on topic for all the groups selected.

The Breidbart cancel index, the formula that decides when a message is
enough spam like that it is legitimate for anyone to issue a cancel for
it highly favors cross posting, in that a message counts as only the
square root of the number of groups it has been cross posted to.

That doesn't mean that it is never appropriate to multipost.
Cross-posting has the advantage that everyone sees the whole
conversation, so it stays coherent. When asking a question that is a mix
of different knowledge areas, the cross-fertilization in the cross-post
tends to improve the answer, but not always.

There are some questions where you may be looking for multiple
independent opinions, and therefore you ask in different groups that are
still on topic for the question, but you don't want arguements between
the groups, and that would be a good case for mulit-posting.

There may well be more people who prefer multi-posting over cross
posting, but I suspect that if you weight based on their ability to
actually know that answer and be able to help you, the bias swings
strongly to cross-posting.

Now, in this case, the question is likely really only on topic for one
of the groups, as the program in question is likely either a C program
or a C++ program, so should be asked only in the right language
newsgroup. Few things are really appropriate to be posted to both
groups, maybe something specifically asking about a comparison between
the two languages, or dealing with interfacing them.

[toc] | [prev] | [next] | [standalone]

#148328

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2019-11-29, Frederick Gotham wrote:
>
>> I have a 3rd party library which is 50 - 100 source files.
>
> ...
>
> You also posted this to comp.lang.c++. Please don't multipost!
>
> It's better to cross-post, i.e. send the same posting to both groups.
> That way a c.l.c reader can see that a c.l.c++ responded and save
> himself the trouble, or maybe clarify.  You get better answers, and
> everyone else wastes less time repeating the same information.

IME threads that start off being cross-posted to c.l.c and c.l.c++
usually generate more pointless and/or off-topic discussion than
would have occurred if the original posting had been made separately
to the individual newsgroups (often called multi-posting).  So I
for one am happy to see that this question was posted separately
rather than being cross-posted.

[toc] | [prev] | [next] | [standalone]

#148330

In article <8636e46j3r.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Fri, 2019-11-29, Frederick Gotham wrote:
>>
>>> I have a 3rd party library which is 50 - 100 source files.
>>
>> ...
>>
>> You also posted this to comp.lang.c++. Please don't multipost!
>>
>> It's better to cross-post, i.e. send the same posting to both groups.
>> That way a c.l.c reader can see that a c.l.c++ responded and save
>> himself the trouble, or maybe clarify.  You get better answers, and
>> everyone else wastes less time repeating the same information.
>
>IME threads that start off being cross-posted to c.l.c and c.l.c++
>usually generate more pointless and/or off-topic discussion than
>would have occurred if the original posting had been made separately
>to the individual newsgroups (often called multi-posting).  So I
>for one am happy to see that this question was posted separately
>rather than being cross-posted.

Yes!  100% correct.  And dead on about the specific character of CLC (*)
being a noise-generator.  As I proved and demonstated years ago, it cannot
ever be correct to have a newsgroup set (for a post) that:
    1) Includes clc
    2) Includes any other group

In short, clc stands alone.

(*) I've not spent much time reading CLC++, so I can't comment on that.

-- 
Modern Christian: Someone  who can take time out  from using Leviticus
to defend  homophobia and  Exodus to plaster  the Ten  Commandments on
every school and courthouse to claim  that the Old Testament is merely
"ancient laws" that "only applies to Jews".

[toc] | [prev] | [next] | [standalone]

#148342

On Sun, 2019-12-01, Tim Rentsch wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Fri, 2019-11-29, Frederick Gotham wrote:
>>
>>> I have a 3rd party library which is 50 - 100 source files.
>>
>> ...
>>
>> You also posted this to comp.lang.c++. Please don't multipost!
>>
>> It's better to cross-post, i.e. send the same posting to both groups.
>> That way a c.l.c reader can see that a c.l.c++ responded and save
>> himself the trouble, or maybe clarify.  You get better answers, and
>> everyone else wastes less time repeating the same information.
>
> IME threads that start off being cross-posted to c.l.c and c.l.c++
> usually generate more pointless and/or off-topic discussion than
> would have occurred if the original posting had been made separately
> to the individual newsgroups (often called multi-posting).  So I
> for one am happy to see that this question was posted separately
> rather than being cross-posted.

If it had been something likely to trigger a language flamewar
I would have agreed and not recommended cross-posting.

BTW, /if/ one decides to multipost, I think the message should start
with something like "I posted this to the following newsgroups: ..."
so people see that they may be wasting their time by replying.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web