Hi, people, I propose to move Debug and Object File related headers out of Support

From my point of view, the Support library should be more pure. And

should not contains
too much LLVM-related APIs and defines,

Where would you like to move them?

-eric

CallSite is another that doesn't really make sense to be in Support

For example,
ELF.h MachO.h and COFF.h
should moved into Object directory with new name.
and Dwarf.h should moved into DebugInfo directory.

Going to be interesting layering issues if you do the latter. Then you
have CodeGen depending upon DebugInfo instead of just a header in
Support.

-eric

Well, the issue is that LLVM's "libraries" are really not fine grained due
to our build system/source tree layout, so we end up just glomming together
large pieces of (sometimes vaguely) related functionality into "libraries",
which are the units of physical dependency. Realistically, Support/ELF.h is
a fine piece of independent functionality that should be independently
reusable, but we don't have effective tools for managing and maintaining
proper physical dependencies to make that happen.

There are actually a bunch of things in Support that I wish could be
independently reused. Like if I want to write up a little program, I really
wish I could do

$ llpm install StringRef ArrayRef raw_ostream MemoryBuffer

and then have it put those relevant modules and their dependencies in a
local `deps/` (or whatever) directory so that I can then just include them
in my build.

-- Sean Silva

Going to be interesting layering issues if you do the latter. Then you
have CodeGen depending upon DebugInfo instead of just a header in

That's really bothered me, CodeGen include Dwarf.h and not depending
on DebugInfo?
That's a bit weird. Maybe we should rethink is that really need to
include Dwarf.h in CodeGen.
And, besides, CodeGen also includes Target files, so why CodeGen
didn't dependent on Target?

LLVM is a modularized software system, so I hope it's was modularized,
And ELF.h is definitely belongs to Object by classification,
The things that confused me is the ELF.h was placed under Support and
don't know why.
Indeed, I checked that those source codes that include ELF.h also
include files under Object folder,
so that's the reason to move ELF.h from Support to Object.

Because it's also used by the MC layer's direct object emission support.

Chip

在 2013-7-4 下午8:53,“Charles Davis” <cdavis5x@gmail.com>写道:

LLVM is a modularized software system, so I hope it’s was modularized,
And ELF.h is definitely belongs to Object by classification,
The things that confused me is the ELF.h was placed under Support and
don’t know why.
Because it’s also used by the MC layer’s direct object emission support.
thanks for your response, did MC layer’s direct object emission depends on Object library?

Nope. The Object library only reads object files. MC, on the other hand, only writes object files.

Chip

在 2013-7-4 下午8:53,"Charles Davis" <cdavis5x@gmail.com>写道:
>
>
>
> > LLVM is a modularized software system, so I hope it's was modularized,
> > And ELF.h is definitely belongs to Object by classification,
> > The things that confused me is the ELF.h was placed under Support and
> > don't know why.
> Because it's also used by the MC layer's direct object emission support.
thanks for your response, did MC layer's direct object emission depends on
Object library?

Nope. The Object library only reads object files. MC, on the other hand,
only writes object files.

That’s true for object emission, but MC already depends on libObject, and
at least some of the more experimental parts of MC actually use it to read
files.

However, - I believe nobody mentioned this - I think the point of having
ELF.h and friends in Support is that they’re intended to (more or less
exactly) match the headers provided by the system. Most of what’s there is
duplicated in a friendlier form (for ObjectFile-related stuff), or just to
match the LLVM style (notably Object/MachOFormat.h) in Object.

-- Ahmed Bougacha

Huh. You’re right, looking at MC’s LLVMBuild.txt file.

That’s right, the new object disassembler stuff (that you are working on, if I’m not mistaken!) that was just added needs libObject.

But as for debug info, it is true that DebugInfo only knows how to read it, and CodeGen knows how to write it (but not read it). So for now, the DWARF stuff at least definitely needs to stay in Support.

Agreed, though I’m not sure if that justifies them being in Support instead of Object.

I have to say, I believe that this duplication is an (admittedly minor) problem, because now at least <llvm/Support/MachO.h> and <llvm/Object/MachOFormat.h> are out of sync. I think we should get rid of one in favor of the other. Personally, I want to keep the former and dump the latter, but LLVM uses mostly the latter when it needs to work with Mach-O files, so I’m not sure how the rest of the community feels–which header stays and which one goes, where the header should go, or if this is even a bike shed they’d want to repaint.

Chip