Non-static global variables cause relocation to fail
I tried to find documentation on this, but couldn't.
I've discovered, on PowerPC 85xx systems at least, that the mere presence of a non-static global variable, even if it isn't used by any code, will cause relocation to fail. Exactly how it fails, I can't say, but U-Boot does hang.
If I make the global variable static, the problem goes away. Note that I have no code that actually references the variable. It just sits there, occupying space.
Fortunately, the data structure doesn't need to be non-static. I just forgot to put 'static' in its definition. Of course, it would have been nice to know this up front.
Can someone explain why this is the case? Do I need to do anything special in my code to access global variables, static or not static?
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 9 lines · In message <[email protected]> you wrote:
I tried to find documentation on this, but couldn't.
I've discovered, on PowerPC 85xx systems at least, that the mere presence of a non-static global variable, even if it isn't used by any code, will cause relocation to fail. Exactly how it fails, I can't say, but U-Boot does hang.
If I make the global variable static, the problem goes away. Note that I have no code that actually references the variable. It just sits there, occupying space.
Quoted 6 lines
Fortunately, the data structure doesn't need to be non-static. I just forgot to put 'static' in its definition. Of course, it would have been nice to know this up front.
Can someone explain why this is the case? Do I need to do anything special in my code to access global variables, static or not static?
You don't seriously expect any real help given such a vague description? It would be somewhat helpful if you said exactly which changes cause the code to work or fail...
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I am not now, nor have I ever been, a member of the demigodic party.
-- Dennis RitchieQuoted 3 lines · Wolfgang Denk
You don't seriously expect any real help given such a vague description? It would be somewhat helpful if you said exactly which changes cause the code to work or fail...
I did say that. Simply making the global variable not static caused it to fail.
Works:
static struct __attribute__ ((__packed__)) eeprom {
Doesn't work:
struct __attribute__ ((__packed__)) eeprom {
Everything else is the same.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 2 lines · In message <[email protected]> you wrote:
I did say that. Simply making the global variable not static caused it to fail.
Ummm... I guess there must be more than one variable in U-Boot, as there are several source files and several board configurations.
Also, there are several tool chains being used.
You provide NONE of that *essential* information.
Quoted 9 lines
Works:
static struct
__attribute__((__packed__)) eeprom {Doesn't work:
struct
__attribute__((__packed__)) eeprom {Everything else is the same.
What is "same"? Which source file is this? Which line? Which board? Which compiler from which distro? Which binutils?
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7
Quoted 5 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> you wrote:
I did say that. Simply making the global variable not static caused it to fail.
Ummm... I guess there must be more than one variable in U-Boot, as there are several source files and several board configurations.
Sorry, I was under the assumption that the problem is not unique to the actual variable in question. That is, making any global variable non-static risks having relocation fail.
I was looking for a more general explanation to the problem. I was hoping that someone who understood the relocation code well could explain to me, in theoretical terms, how this could happen.
Quoted 2 lines
What is "same"? Which source file is this? Which line? Which board? Which compiler from which distro? Which binutils?
This is a new file that I haven't posted yet. It is a replacement for board/freescale/common/sys_eeprom.c. It's currently undergoing internal review.
That's why I asked for a general explanation.
Compiler: powerpc-linux-gnu-gcc (GCC) 4.2.1
Binutils: GNU ld (GNU Binutils) 2.18.50.20070820
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 4 lines · In message <[email protected]> you wrote:
Sorry, I was under the assumption that the problem is not unique to the actual variable in question. That is, making any global variable non-static risks having relocation fail.
Hm...as you will notice, there are many global vaiables being used without problems, so I don't easily buy such a very general statement.
Quoted 1 line
I was looking for a more general explanation to the problem. I was hoping that
How about analyzing your specific problem instead of assuming that it is a general problem?
Did you, for example, try changing another static variable in another source file for another, known to be working board, and observe the same problem?
Or why exactly do you assume it is a general problem?
Quoted 1 line
This is a new file that I haven't posted yet. It is a replacement for
Ah. So there is a chance that it's just bugs in your new code?
Quoted 1 line
That's why I asked for a general explanation.
Sounds unreasonable to me.
Quoted 2 lines
Compiler: powerpc-linux-gnu-gcc (GCC) 4.2.1
Binutils: GNU ld (GNU Binutils) 2.18.50.20070820
Hm... did you try another, maybe less recent, toolchain, with the same results?
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Landing: a controlled mid-air collision with a planet.
Quoted 10 lines · Timur Tabi
Quoted 3 lines · Wolfgang Denk
You don't seriously expect any real help given such a vague description? It would be somewhat helpful if you said exactly which changes cause the code to work or fail...
I did say that. Simply making the global variable not static caused it to fail.
Works:
Quoted 7 lines
static struct
__attribute__((__packed__)) eeprom {Doesn't work:
struct
__attribute__((__packed__)) eeprom {Everything else is the same.
Hi Timur,
That isn't a variable, that is the first line of a struct declaration. You cut some pretty important information: what the struct is, the actual variable in question, and whether it is initialized.
I'm guessing from the name "eeprom" that you have a non-zero initializer on it??? Does it make a difference if it is uninitialized, initialized to {0}, or initialized to non-zero values?
Does it make a difference if it is packed or not (my guess: much less likely than initialization to cause works/broken).
Best regards,
gvb
Quoted 1 line · Jerry Van Baren
That isn't a variable, that is the first line of a struct declaration.
I didn't include this part (although since the code compiles, it should be obvious that it exists):
} e;
So I'm defining a global variable called 'e'. Perhaps the short name is part of the problem.
Quoted 2 lines
You cut some pretty important information: what the struct is, the actual variable in question, and whether it is initialized.
As Wolfgang pointed out, my assumption that this is a generic problem is flawed, and it's most likely a problem with my specific implementation.
Quoted 2 lines
I'm guessing from the name "eeprom" that you have a non-zero initializer on it???
No, no initializer.
Quoted 2 lines
Does it make a difference if it is uninitialized, initialized to {0}, or initialized to non-zero values?
I don't know, I haven't considered it.
I did notice this code in fsl_i2c.c:
#ifdef CFG_SPD_BUS_NUM
static unsigned int i2c_bus_num __attribute__ ((section ("data"))) = CFG_SPD_BUS_NUM;
#else
static unsigned int i2c_bus_num __attribute__ ((section ("data"))) = 0; #endif
I wrote this code, but I don't remember why I added the "__attribute__ ((section ("data")))". I guess I should have commented it, but I wonder if it applies to my current problem.
Quoted 2 lines
Does it make a difference if it is packed or not (my guess: much less likely than initialization to cause works/broken).
It needs to be packed, otherwise the code won't work. Sadly, someone defined a 4-byte integer at address 0x72 in the EEPROM.
When I post the full patch, I'll revisit this problem. Sorry for all the noise.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 10 lines · In message <[email protected]> you wrote:
I did notice this code in
fsl_i2c.c:#ifdef
CFG_SPD_BUS_NUM
static unsigned inti2c_bus_num__attribute__((section ("data"))) =CFG_SPD_BUS_NUM;
#else
static unsigned inti2c_bus_num__attribute__((section ("data"))) = 0; #endif
Quoted 3 lines
I wrote this code, but I don't remember why I added the "
__attribute__((section ("data")))". I guess I should have commented it, but I wonder if it applies to my current problem.
Most probably you reference these variables before the bss has been set up and initialized, i. e. before relocation to RAM, and you wanted to make sure that they are really initialized with zero.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Good morning. This is the telephone company. Due to repairs, we're giving you advance notice that your service will be cut off indefi- nitely at ten o'clock. That's two minutes from now.
Quoted 1 line · Timur Tabi
Jerry Van Baren wrote:
[snip]
Quoted 19 lines
Quoted 2 lines
I'm guessing from the name "eeprom" that you have a non-zero initializer on it???
No, no initializer.
Quoted 2 lines
Does it make a difference if it is uninitialized, initialized to {0}, or initialized to non-zero values?
I don't know, I haven't considered it.
I did notice this code in
fsl_i2c.c:#ifdef
CFG_SPD_BUS_NUM
static unsigned inti2c_bus_num__attribute__((section ("data"))) =CFG_SPD_BUS_NUM;
#else
static unsigned inti2c_bus_num__attribute__((section ("data"))) = 0; #endif
Quoted 3 lines
I wrote this code, but I don't remember why I added the "
__attribute__((section ("data")))". I guess I should have commented it, but I wonder if it applies to my current problem.
It doesn't apply in the original complaint and may be flat out wrong, but I recall having a problem forcing a zero initializer into the data section. Gcc insisted on putting it in bss and, after playing language lawyer with the gcc manual/descriptions/etc, I concluded it was expected behavior of gcc.
[snip]
Quoted 1 line
When I post the full patch, I'll revisit this problem. Sorry for all the noise.
Interesting quirk. We may give you a hard time, but that just betrays our curiosity. ;-)
Best regards,
gvb